Après l'automatisation
Auteur original : Dan Shipper, Every CEO
Compilé par Peggy, BlockBeats

Note de la rédaction : Récemment, la discussion sur l'IA et le travail a été presque entièrement dominée par une question : à mesure que les capacités des modèles continuent de s'améliorer, les postes de cadre seront-ils massivement remplacés ? Des générateurs de code à l'automatisation du service client en passant par la production de contenu, les agents prennent progressivement en charge des tâches intellectuelles qui nécessitaient auparavant une intervention humaine. Les tests de référence renforcent également cette anxiété : les performances des modèles en matière de raisonnement au niveau du diplômé, de tâches économiques réelles et de重构 de code au niveau d'ingénieurs seniors s'améliorent rapidement, semblant approcher un point critique où le travail humain sera englouti par l'automatisation.

Mais Every CEO Dan Shipper présente dans cet article une observation opposée : plus l'automatisation s'intensifie, plus le travail humain augmente. Every est un utilisateur approfondi d'agents IA et a intégré des outils tels que Codex, Claude Code, Slack Agent et des agents de service client dans ses processus de codage, d'écriture, de conception, de service client et de gestion. Toutefois, le résultat n'est pas une substitution totale des employés, mais une restructuration des formes de travail : les ingénieurs ne se contentent plus d'écrire du code, mais examinent,重构ent et conçoivent des systèmes ; les rédacteurs ne rédigent plus uniquement des articles, mais déterminent ce qui mérite d'être écrit et comment le rendre différent ; les agents de service client ne traitent plus chaque demande basique, mais maintiennent un système capable de répondre automatiquement aux clients.

Ce qui mérite le plus d’attention dans cet article, ce n’est pas « si l’IA peut accomplir une tâche », mais le fait qu’elle redéfinit la place de l’humain dans le travail intellectuel. L’IA excelle à rendre bon marché les compétences déjà acquises : le code, les textes, les miniatures, les réponses au service client, les descriptions de produits, les rapports de recherche, peuvent tous être générés rapidement par des modèles. Mais lorsque ces compétences deviennent accessibles à tous, ce qui émerge souvent sur le marché, ce n’est pas une production de haute qualité et différenciée, mais une multitude de « sorties par défaut » semblables, dépourvues de jugement et de contexte. Autrement dit, l’IA marchandise les « compétences humaines d’hier », tandis que ce qui est véritablement rare, c’est la capacité de jugement face aux problèmes concrets du présent.

Ainsi, l'automatisation n'a pas éliminé les experts, mais a créé davantage de scénarios nécessitant leur intervention. Lorsque les opérateurs peuvent soumettre du code via l'IA, les ingénieurs doivent déterminer quels codes méritent d'être fusionnés ; lorsque les marketeurs peuvent générer des miniatures en quelques secondes, les designers doivent juger ce qui correspond à la marque et aux objectifs de communication ; lorsque les ingénieurs peuvent également rédiger des articles, les éditeurs doivent transformer les brouillons en contenus véritablement argumentés, structurés et prêts à être publiés. L'IA élargit la portée de la production et amplifie la demande en matière de contrôle de qualité, de construction de systèmes, de délimitation des frontières et d'expression différenciée.

L'auteur explique davantage ce paradoxe à l'aide d'analyses de référence. Que ce soit le Senior Engineer Benchmark ou le GDPval d'OpenAI, les scores des modèles ne mesurent pas l'« intelligence » en tant que concept abstrait, mais plutôt la performance du modèle dans un cadre de problème spécifique. Les invites, les limites de la tâche, les critères d'évaluation et le format de sortie contiennent déjà un grand nombre de jugements humains. Le modèle peut progresser rapidement à l'intérieur du cadre, mais ce cadre est établi par les humains ; dès qu'un cadre est résolu par le modèle, les humains déplacent le problème vers un nouveau cadre plus complexe.

C’est aussi la réponse la plus intéressante de cet article à l’anxiété liée à l’AGI : même si les modèles deviennent de plus en plus puissants, ils ne rattrapent souvent que la frontière tracée par les humains, et non les humains eux-mêmes qui l’ont tracée. L’IA peut exécuter des objectifs, optimiser des chemins et améliorer l’efficacité, mais tant qu’elle reste à répondre à des questions posées par les humains, elle manque toujours d’une subjectivité véritable. L’avenir du travail intellectuel ne réside pas dans la disparition des humains des processus, mais dans leur transition vers des rôles de concepteurs de cadres, de mainteneurs de systèmes, d’évaluateurs de qualité et de définitions du sens.

Après automatisation, la valeur du travail humain n'a pas disparu, elle est simplement devenue plus difficile, plus stratégique et plus dépendante du jugement. L'IA rend « savoir faire » bon marché, mais rend plus rare « savoir ce qui vaut la peine d'être fait, pourquoi le faire, et à quel point il faut le faire pour être bon ».

The following is the original text:

Au cœur de l'IA, il existe un paradoxe.

Chez Every, nous avons automatisé autant de tâches que possible. Que ce soit pour la programmation, l'écriture, le design, le service client ou d'autres tâches quotidiennes, nous utilisons Codex et Claude Code. Nous participons également aux tests alpha avant la publication officielle des nouveaux modèles d'OpenAI, d'Anthropic et de Google. On peut dire que nous nous embarquons aussi vite et aussi profondément que possible dans la vague d'augmentation exponentielle de l'intelligence et des capacités d'automatisation des modèles.

Mais paradoxalement, pour nous, le travail que les humains doivent accomplir semble plus important que jamais. Every est actuellement une équipe de près de 30 personnes, et nous n'avons pas licencié tous nos employés parce que nous avons des Agents ; nous n'avons pas non plus abandonné les outils SaaS pour nous fier entièrement aux applications créées par du vibe coding. Nous continuons à recruter des agents clientèle humains, mais ils bénéficient d'un soutien important de la part des Agents ; nous recrutons également toujours des auteurs, des éditeurs et des ingénieurs.

Cependant, la nature du travail a effectivement considérablement évolué. Nous ne codons presque plus à la main. Si vous mentionnez quelqu’un sur Slack, il n’est pas toujours facile de déterminer si c’est une personne ou un agent. Les managers commencent à soumettre du code comme des contributeurs individuels, tandis que les ingénieurs interagissent directement avec les clients. Au cours des dernières semaines, 95 % de mes e-mails professionnels ont été rédigés par l’IA. Ma boîte de réception reste presque toujours vide — ce qui est extrêmement rare pour moi — mais je vérifie quand même chaque e-mail individuellement.

In other words, the future looks unfamiliar, yet strangely familiar.

Ce « sentiment de familiarité » est en soi surprenant. Car que ce soit le PDG, un travailleur du savoir ou un investisseur, il semble que de plus en plus de personnes croient à une même chose : l’IA menace l’emploi, l’économie, la sécurité, voire le sens même du travail humain.

Le PDG d'Anthropic, Dario Amodei, a averti que l'IA pourrait éliminer jusqu'à la moitié des postes de bureau débutants. Meta vient de licencier 8 000 personnes et commence à installer des logiciels sur les ordinateurs des employés aux États-Unis pour enregistrer les mouvements de la souris, les clics et les frappes au clavier, afin d'obtenir des données d'entraînement de meilleure qualité pour les emplois de connaissance avancée.

Même Ken Griffin, fondateur de Citadel, semble profondément surpris. Il a récemment déclaré : « Ce ne sont pas des postes de cadres moyens ou inférieurs, mais des postes à très haut niveau de compétences, qui sont en cours d’automatisation — je réfléchis au mot exact — par l’IA agente. »

Diverses évaluations de référence semblent également soutenir ce jugement. À mesure que de nouveaux modèles sont régulièrement publiés, les indicateurs de capacité des modèles progressent à un rythme quasi exponentiel. Dans l’évaluation Humanity’s Last Exam, un test de raisonnement de niveau master, les performances des meilleurs modèles sont passées de quelques pourcents il y a un an à environ 44 % aujourd’hui. Dans l’évaluation GDPval, qui mesure la capacité des modèles de pointe à accomplir des tâches économiques réelles et les compare aux performances humaines, les résultats des modèles ont également bondi de niveaux similaires à environ 85 %. En mai de cette année, l’organisation à but non lucratif METR dédiée à la sécurité de l’IA a publié les premiers résultats de test de Claude Mythos : sur certaines tâches qui prennent environ 4 heures à des experts humains, le modèle a atteint un taux de réussite de 80 %.

Il semble que nous soyons sur le point de franchir une ligne critique : une IA plus intelligente que tout être humain, capable de travailler de manière autonome et continue pendant presque une journée entière, est sur le point de devenir une réalité.

Cependant, le paradoxe persiste. Si vous discutez avec des professionnels de l'industrie de l'IA ou avec les premiers utilisateurs de l'IA en dehors du secteur, vous entendrez la même conclusion que celle que nous avons observée internement : il faut accomplir davantage de travail qu'auparavant.

La question qui intéresse vraiment les professionnels du secteur est la suivante : s'agit-il simplement d'un état transitoire ? La prochaine version du modèle sera-t-elle celle qui remplacera enfin tout le monde ? Nous suivons les courbes de référence, à la fois excités et tendus, craignant qu'un point de bascule ne survienne à tout moment, entraînant la disparition soudaine d'un grand nombre d'emplois.

Mais je ne pense pas qu’un tel « point critique » va surgir du jour au lendemain, inversant brusquement tout et faisant disparaître massivement les emplois. La nouvelle réalité est exactement l’inverse : plus l’automatisation est élevée, plus les travaux nécessitant la participation d’experts humains augmentent.

La raison en est que l’IA est en train de marchandiser les composantes des compétences humaines qui peuvent être explicitement exprimées, formées et reproduites. Tout savoir pouvant être formulé en règles, consolidé en processus ou transformé en données d’entraînement devient progressivement une capacité par défaut des modèles. En conséquence, la valeur produite par les modèles courants est rapidement dépréciée, et le marché commence à exiger avec davantage d’insistance ce qui est différent.

La demande pour « quelque chose de différent » est, en essence, une demande pour des experts humains. Même si nous approchons de l'intelligence artificielle générale, cela ne disparaîtra pas.

Pour comprendre la raison, il ne suffit pas de regarder uniquement les courbes de benchmark ou de se concentrer uniquement sur les classements de paramètres et de capacités des modèles. Nous devons revenir aux scénarios réels d'utilisation et observer comment l'IA est effectivement utilisée aujourd'hui. Seule cette approche permet de comprendre véritablement ce paradoxe et sa réponse sous-jacente.

Comment en sommes-nous arrivés là ?

Depuis 2022, nous suivons l'impact des agents sur le travail de l'avenir.

Il y a trois ans, j’ai écrit un article sur l’« économie d’allocation ». À l’époque, mon jugement était que collaborer avec des outils d’IA finirait par ressembler de plus en plus au travail d’un gestionnaire humain : vous ne réalisez plus vous-même chaque action, mais vous décomposez, attribuez, surveillez et validez les tâches. À cette époque-là, les questions et réponses les plus basiques dans ChatGPT étaient encore considérées par beaucoup comme quelque chose d’extrêmement futuriste, voire un peu inquiétant.

D'ici le milieu de l'année 2025, l'entreprise Every était presque entièrement « Claude Codeifiée ». Kieran Klaassen, directeur général de Cora, a soudainement réalisé qu'il pouvait abandonner l'écriture manuelle de code pour passer toute la journée à donner des instructions en langage naturel à un agent de programmation dans un terminal. Ce mode de travail s'est rapidement répandu dans toute l'entreprise. Il y a environ 12 mois, sur le podcast de Lenny, j'ai dit que Claude Code était l'outil le plus sous-estimé dans le travail intellectuel.

Je mentionne cela parce que certains de nos jugements les plus précis par le passé proviennent de l'observation de Every comme d'un laboratoire pour les premiers utilisateurs. De nombreux nouveaux modèles de travail apparaissent d'abord en interne ; une fois que la technologie s'affine et que les outils deviennent plus faciles à utiliser, ces modèles s'étendent progressivement au marché plus large.

Et maintenant, de nouveaux changements se produisent en interne.

Deux modes de collaboration avec Agent

Autour du fonctionnement de l'IA, les choses tendent progressivement à se diviser en deux modèles très différents.

Le premier type, déjà assez précisément anticipé dans les discussions précédentes sur l'IA : considérer les agents comme des employés. Ces agents peuvent se voir attribuer des tâches. Certains agents vivent dans Slack, possèdent un nom et des responsabilités propres ; lorsque vous avez besoin qu'ils accomplissent une tâche, vous pouvez simplement les mentionner directement avec @. D'autres agents sont intégrés à des flux de travail en cours d'exécution, comme les systèmes de service client, servant d'entrée et de filtre 24/7 pour les tâches répétitives.

Le deuxième mode est plus étrange, mais dans mon expérience, il est aussi plus important. Il s'agit de la collaboration entre l'humain et les agents dans des outils tels que Codex, Claude Code et Claude Cowork. Ces outils ne sont pas simplement des endroits où vous déléguer des tâches ; ils deviennent le système d'exploitation même du travail : vous utilisez simultanément plusieurs agents sur le même « ordinateur », dans un environnement de travail partagé, pour accomplir des tâches hautement complexes, originales et impossibles à confier simplement à un agent asynchrone.

Dans les deux modes, vous pouvez automatiser et déléguer une grande partie du travail avec l’IA. Mais pour que les deux modes fonctionnent vraiment bien, vous ou un autre humain devez toujours participer.

Un agent est une entité à laquelle vous confiez une tâche ; elle s'engage ensuite indépendamment, sans votre participation en temps réel, pour produire une réponse, une action, un rapport, un brouillon ou une décision de routage.

Ces agents existent sous au moins deux formes : un « agent collègue » et un « agent intégré ».

1. Agent de type collègue

Un agent de type collègue est un agent que vous pouvez appeler dans Slack comme si vous tagguiez un collègue pour lui demander d’accomplir une tâche. Il est toujours disponible et peut être invoqué dès que nécessaire. Des produits comme OpenClaw, ou notre développement interne Plus One, relèvent de cette catégorie.

Claudie

Claudie est un agent de type collègue utilisé par notre équipe de conseil. Il rédige des propositions commerciales, génère des brouillons de documents de formation, suit les tâches en attente des projets et peut gérer d'autres travaux similaires.

Andy

Andy est un agent de type collègue utilisé par notre équipe d'édition. Il collecte sur le Slack interne de l'entreprise des « points d'inspiration » méritant un approfondissement — c'est-à-dire de bonnes idées susceptibles de devenir des articles — et les synthétise en résumés et opinions initiales, destinés aux rédacteurs pour la rédaction de la lettre d'information quotidienne.

Viktor

Viktor est un agent polyvalent chargé de tâches transversales au sein de l'entreprise. Nous l'utiliserons pour collecter des indicateurs de croissance, analyser les résultats d'enquêtes utilisateurs, et transformer les discussions internes désordonnées en notes de recherche et recommandations produit.

2. Agent intégré

Les agents intégrés sont incorporés dans des flux de travail produits spécifiques. Ils sont moins flexibles que les agents collègues, mais sont souvent très efficaces pour traiter des tâches répétitives.

Fin est l'exemple le plus clair. C'est un agent intégré à notre plateforme de service client qui peut assumer un grand nombre de tâches de support via le chat et les e-mails.

Au cours d'une semaine de mai de cette année, Fin a participé à 65 % des 202 conversations client d'Every et a fermé de manière autonome 81 tickets, soit 40,1 % de toutes les conversations traitables.

Ces agents intégrés permettent à notre manager du service client, Waqqas Mir, de consacrer moins de temps à répondre aux tickets de base, et davantage d’efforts à la création d’un système capable de répondre automatiquement aux tickets, ainsi qu’à la gestion de cas clients nécessitant un contact plus étroit et des jugements plus complexes.

Que ce soit des agents de type collègue ou des agents intégrés, le modèle sous-jacent reste le même : les agents prennent en charge davantage de tâches stables, répétitives et aux frontières bien définies.

Mais il reste encore beaucoup de travail qui doit être effectué par des humains. Nous avons constamment constaté que, dès lors qu'une tâche est suffisamment complexe et que l'on souhaite obtenir des résultats de haute qualité, la meilleure approche n'est pas de confier entièrement le travail à l'IA, mais de permettre une collaboration réciproque entre l'IA et les humains dans un même espace de travail.

C’est précisément la valeur des outils comme Codex, Claude Code et Cowork. Ils vous permettent de lancer un ou plusieurs Agents dans plusieurs fils de discussion et de leur déléguer des tâches. Ces Agents peuvent accéder à votre ordinateur et à toutes les sources de données pertinentes. Vous pouvez voir quelle tâche chaque Agent exécute, comment il réfléchit, et vous pouvez l’interrompre à tout moment.

En parallèle, vous devez toujours gérer ces agents : définir clairement la direction au début de chaque tâche, vérifier la qualité à la fin, garantir que les résultats sont suffisamment bons, et continuer à identifier les prochaines tâches méritant d'être poursuivies. Kieran appelle ce rôle l'« sandwich » humain — l'IA gère la partie centrale, tandis que l'humain agit comme les deux tranches de pain, encadrant le début et la fin de la tâche.

« Sandwich humain ». Source : Every.

L'exemple le plus typique est l'écriture de code. Chez Every, les ingénieurs collaborent presque toute la journée avec des agents. Ils planifient ensemble de nouvelles fonctionnalités ou corrigent des bogues, examinent le travail déjà accompli ; et s'ils adoptent la notion de « génie composé » (compound engineering), ils optimisent constamment leur système pour le rendre de plus en plus efficace avec le temps.

Mais cette façon de collaborer va bien au-delà du codage.

Codex et Claude Code deviennent un nouveau système d'exploitation de travail. Je passe presque toute la journée dans Codex, en exécutant divers outils SaaS via son navigateur intégré. Il me permet d'apporter un Agent à chaque scénario de travail et d'atteindre un niveau de productivité que je ne pourrais pas atteindre seul.

Écrire

Cet article a été rédigé dans le navigateur intégré de Codex, à l’aide de Proof. Codex observe ce que je suis en train d’écrire et peut lancer à tout moment un sous-agent pour accomplir n’importe quelle tâche dont j’ai besoin : rédiger un premier brouillon d’un passage, rechercher des exemples pour la partie suivante, ou effectuer une édition et une mise en forme du texte.

Écrivez cet article via Proof dans Codex. Source : Every.

Email

Lorsque je traite les e-mails, j'emploie la même méthode. Cora est mon client de messagerie ; j'ouvre celui-ci dans le navigateur intégré de Codex, tout en vocalisant ma réflexion pour chaque e-mail via Monologue tout en parcourant ma boîte de réception. Le reste est pris en charge par Codex et Cora.

Un nettoyage de boîte de réception effectué par Cora. Source : Every.

Dans tous les scénarios automatisés ci-dessus, vous avez probablement pu voir où intervient l'humain. Dans chaque exemple, l'agent a besoin de la participation humaine pour que le travail fonctionne réellement.

Quelqu'un doit orienter la question correctement, évaluer si le résultat est suffisamment bon, identifier les erreurs et transformer les résultats en décisions ou processus concrets.

Plus un Agent est éloigné de la personne chargée de surveiller sa performance, moins il fonctionne bien. Au début de notre déploiement interne, nous avions attribué un Agent à chaque employé. Mais nous sommes rapidement revenus à une approche où les Agents servent une équipe spécifique ou l'ensemble de l'entreprise, et non un individu en particulier.

La raison est simple : les agents nécessitent une maintenance intensive. Dès qu’un utilisateur abandonne la surveillance de son agent personnel, celui-ci devient rapidement obsolète et inopérant. Nous disposons d’une équipe d’ingénieurs IA dédiée à garantir que ces agents fonctionnent de manière stable et efficace. Et dans un avenir prévisible, nous aurons toujours besoin de cette équipe. Même une tâche apparemment simple comme « générer automatiquement une présentation PowerPoint » peut se transformer en un projet système complexe. L’un de nos processus d’automatisation PowerPoint comprend ainsi 24 compétences et 18 scripts, avec un coût en tokens de 62 dollars pour générer une présentation.

C'est la première raison pour laquelle l'agent crée davantage d'emplois pour les humains.

Mais il y a une deuxième raison.

Pourquoi l'automatisation entraîne-t-elle plus de travail pour les humains ?

Si vous observez la croissance exponentielle des capacités de l'IA au cours des dernières années, combinée à sa structure et à la source de ses capacités, vous constatez un cycle de rétroaction clair : elles créent continuellement davantage de travail humain.

L'IA rend les capacités humaines d'hier bon marché

Les modèles de langage actuels sont formés sur les traces visibles laissées par les humains : code, articles, images, tickets de support, documents de spécifications produit, et bien d'autres encore. Ils absorbent ces contenus — c'est-à-dire les « échappements » des tâches déjà réussies — puis les reconditionnent sous une forme peu coûteuse et accessible à tous.

Le résultat est que de nombreuses compétences autrefois rares, comme soumettre une demande d’intégration de code, créer une miniature YouTube ou rédiger une lettre d’information, sont désormais accessibles à presque tout le monde.

Les capacités peu coûteuses seront rapidement adoptées

Lorsque le coût d'une ressource autrefois rare diminue, son offre augmente rapidement.

Chez Every, nous avons constaté ce changement : les équipes opérationnelles et service client commencent à écrire du code et à soumettre des pull requests ; les marketeurs commencent à créer des miniatures YouTube ; les ingénieurs et les produits commencent également à rédiger des articles, des guides et des brouillons de pages de destination, ce qui n'était auparavant pas de leur ressort.

Ce changement se produit également en dehors d'Every. À titre d'exemple, le projet OpenClaw, un agent IA open source, a reçu, au 16 mai 2026, 44 469 demandes d'intégration sur son dépôt de code, dont 12 430 après le 1er avril et 3 990 après le 1er mai. C'est un nombre impressionnant. À titre de comparaison, Kubernetes, l'un des projets open source les plus populaires au monde, n'a reçu que 5 200 demandes d'intégration sur l'ensemble de l'année 2022.

L'abondance entraîne l'homogénéisation : les compétences des anciens experts sont devenues des biens standardisés

Étant donné que tout le monde utilise le même modèle, et que ces modèles sont tous basés sur les capacités humaines d'hier, les résultats produits par défaut se situent généralement entre un « bon point de départ » et du « contenu purement indésirable généré par l'IA ».

Le terme « contenu de mauvaise qualité » ne désigne pas une erreur spécifique. Ce n'est pas un excès de tirets, ni une formule fixe, ni des accents violets partout sur la page de destination. Il désigne une homogénéité visible, répétée et fatigante.

Lorsque des humains dans différents contextes utilisent les mêmes outils, ceux-ci étant formés sur un même type de corpus, et que les utilisateurs n'effectuent pas de jugements suffisamment approfondis, ce résultat se produit. Autrement dit, lorsque chacun possède un « expert » ayant les mêmes préférences et le même style par défaut, l'homogénéité se produit naturellement.

Lorsque les opérateurs peuvent soumettre des pull requests, que les marketeurs peuvent générer des miniatures YouTube en quelques secondes et que les ingénieurs commencent à rédiger des guides produits, il est facile de se retrouver dans une situation où votre volume de production augmente, mais où la qualité, la cohérence et la différenciation de vos œuvres diminuent.

Mais une fois qu'une chose homogène devient excessivement abondante, elle se transforme rapidement en bien de consommation.

L'homogénéité crée un besoin de différenciation

À cause d'Internet, les humains seront bientôt capables d'identifier ce qui a un goût trop « IA » dans les contenus de chaîne de production. Toute œuvre peut atteindre instantanément d'autres personnes à travers le monde, et c'est souvent le cas. Dès que trop de choses commencent à ressembler les unes aux autres, nous détecterons rapidement quelque chose d'anormal.

Cela signifie que lorsque vous découvrez pour la première fois les capacités d’un nouveau modèle, vous pourriez être impressionné, voire un peu effrayé. Mais quelques mois plus tard, ces capacités deviendront ordinaires. Ce n’est pas que le modèle soit devenu moins puissant, c’est que vos attentes ont changé.

Nous ne nous contentons plus d’une simple application React ou d’un simple rapport d’étude. Nous voulons quelque chose de véritablement adapté à une personne spécifique, à une entreprise précise, à un contexte particulier. Il doit inspirer un sentiment d’exactitude, de vitalité et de concret, et non de bon marché, de généralisation ou de standardisation. Nous souhaitons que son coût de production, qu’il soit temporel ou financier, soit nettement supérieur à son coût de consommation.

Nous voulons des choses qui confèrent un sentiment de statut. Et chaque fois qu'une nouvelle technologie rend les éléments autrefois hautement prestigieux abordables, les humains sont toujours très habiles à inventer de nouveaux jeux de statut pour correspondre aux nouvelles limites de capacité.

Lorsque le travail devient excessivement abondant et que tout semble semblable, les travaux qui ne correspondent pas aux modèles établis deviennent rares, précieux et dotés d’un haut statut.

La demande de différenciation correspond essentiellement à une nouvelle demande en matière d'experts.

En raison des caractéristiques architecturales des modèles linguistiques et de leur diffusion généralisée à presque tout le monde, le travail rare et précieux doit toujours provenir des humains.

Cette génération de modèles ne connaît que les travaux déjà accomplis. Ce que les humains savent, c'est ce qui doit être fait précisément à cet instant.

Dès qu'une situation concrète est réduite à un texte et entrée dans un corpus, elle devient déjà une « chose du passé ». Les humains font face à un moment précis, à un client précis, à une base de code précise, à une conversation précise, tandis que les corpus d'entraînement ne vivent pas véritablement dans ce présent. Cet état de « vivant » ne consiste pas seulement à disposer de données mises à jour. Nous entrons dans le présent avec notre propre histoire, ainsi qu'avec des désirs, des préoccupations et des jugements en constante évolution, pour comprendre ce qui est important. Ce sont précisément ces perspectives en constante mise à jour qui changent ce que nous voyons. Le modèle peut adopter ces perspectives après avoir été invité, mais avant cet appel, il ne les possède pas naturellement.

C'est précisément le paradoxe que nous avons mentionné au départ : rendre le travail des experts moins coûteux ne les remplacera pas simplement. Au contraire, il créera davantage de scénarios nécessitant un jugement d'expert.

Lorsque les opérateurs soumettent une pull request à l'aide de l'IA, vous avez besoin d'ingénieurs pour la réviser.

Lorsque les marketeurs créent des miniatures YouTube, vous avez besoin de designers pour les affiner davantage.

Lorsque les ingénieurs commencent à écrire des articles, vous avez besoin d'auteurs et d'éditeurs pour transformer les brouillons en contenus véritablement lisibles et publiables.

Pour cela, les experts humains se déplaceront simultanément dans les deux directions.

Certains experts utilisent l'IA pour construire des systèmes capables d'absorber et d'exploiter ce flot accru de travail : files d'attente de révision, systèmes d'évaluation, cadres d'exécution, règles de dépôts de code, fichiers d'instructions pour Claude et Codex, intégration continue (CI), gestion des autorisations, ainsi que des flux de travail transformant les brouillons en résultats de haute qualité.

Un autre groupe d'experts utilise l'IA pour accomplir des tâches plus grandes et plus intéressantes qu'ils ne pourraient jamais réaliser seuls. Par exemple, la recherche de vulnérabilités dans des systèmes d'exploitation comme macOS prend généralement plusieurs semaines, voire plusieurs mois. Mais une petite entreprise de sécurité nommée Calif, en utilisant Mythos Preview d'Anthropic, a découvert le premier vulnérabilité de mémoire noyau macOS sur le matériel Apple M5, en seulement cinq jours.

C'est pourquoi, dans la pratique, l'IA ne supprimera pas les emplois basés sur des compétences spécialisées. Ce qu'elle apporte véritablement, c'est une augmentation considérable du volume de travail. Et ces nouvelles tâches ne deviennent différenciées et valorisées que grâce à la participation humaine.

Je ne prétends pas que l'IA créera plus d'emplois pour tous les postes. Le système économique est très complexe, et ce que Every peut observer directement, ce sont les emplois de travail intellectuel expert. En effet, ce type de travail est déjà en train d'être redéfini par l'IA, et de nombreuses entreprises réorganisent actuellement leurs structures autour de ces nouvelles technologies.

Mais je tiens à souligner que, quel que soit votre travail actuel, il existe une forme de travail qui restera toujours en avance sur les modèles : utiliser les modèles pour résoudre les problèmes que vous voyez réellement en ce moment. L'avenir du travail intellectuel se dirige vers là.

Et qu'en est-il du benchmark de croissance exponentielle ?

La réfutation la plus évidente est : regardez les améliorations exponentielles des benchmarks. Tout ce que vous dites maintenant n'est que temporaire ; il suffit d'attendre un peu, et les modèles finiront par rattraper le retard.

Mais il y a un piège à surveiller. Appelons cela « la folie des graphiques » : si vous fixez constamment les prévisions de durée de METR, lisez « AI 2027 », et construisez entièrement vos jugements sur l'avenir en extrapolant les courbes de puissance de calcul, vous risquez facilement de développer une intuition effrayante concernant les progrès des modèles.

Cependant, la meilleure façon de répondre à cette question ne consiste pas seulement à imaginer à quoi ressemblera un modèle futur. Bien sûr, c’est aussi une partie de l’analyse. Plus important encore, il faut examiner comment ces tests de référence ont été conçus. Seule cette approche permet de comprendre plus précisément ce qu’ils révèlent vraiment et quel lien ils entretiennent avec les scénarios réels précédents.

Nous constatons une caractéristique structurelle : tous les tests de référence ont lieu à l’intérieur d’un « cadre » particulier. Pour mesurer quelque chose, vous devez d’abord figer une question sous une forme statique et mesurable. Dès que ce cadre est résolu par le modèle, un léger changement du cadre suffit à faire retomber les performances à un niveau bas. Bien sûr, le modèle continue de progresser au sein du nouveau cadre, mais le même processus se répète inlassablement.

Ainsi, les progrès exponentiels observés sur un certain benchmark sont réels ; mais dès qu’on modifie simplement le cadre de test, ces progrès semblent à nouveau minimes. Ce caractère « fractal » de la saturation des benchmarks reflète en fait, au niveau des graphiques, le même paradoxe que nous avons discuté.

We can see how this mechanism works through a real-world benchmark.

Nous avons développé en interne un benchmark appelé Senior Engineer Benchmark, soit « benchmark d'ingénieur senior ». Comme son nom l'indique, il évalue la capacité des modèles de pointe à accomplir des tâches de programmation de niveau ingénieur senior, comme une grande refactorisation.

Ce test fournira à un agent de programmation un ensemble de code de production déjà hors de contrôle. Il provient de la base de code réelle de Proof : initialement écrit par moi en vibe coding, puis de plus en plus de problèmes sont apparus, jusqu'à ce que je doive faire appel à un ingénieur senior pour le corriger.

L'agent reçoit la base de code avant correction, ainsi qu'une instruction similaire à celle donnée à un ingénieur senior : « Il s'agit d'un ensemble de résultats de vibe coding ; réécrivez-le à partir des principes fondamentaux. »

C'est un bon test de référence, car il évalue non seulement la capacité à compléter le code, mais aussi la capacité d'un agent de programmation à examiner simultanément plusieurs problèmes indépendants et à déterminer s'il possède l'autonomie, la clarté conceptuelle et le courage d'exécution nécessaires pour effectuer une réécriture véritablement fonctionnelle. À titre de comparaison, j'ai conservé les versions de réécriture réalisées par deux ingénieurs seniors humains avec l'aide de l'IA, afin d'évaluer et de comparer les sorties du modèle.

Pour un agent de programmation, cette tâche est difficile. Il doit non seulement identifier la source du problème, mais aussi se souvenir tout au long des interactions successives de la vraie question, sans se laisser détourner par le code existant. En outre, il doit avoir le courage de supprimer de grandes parties de la base de code, ce qui est précisément le type de comportement que les agents sont généralement formés à éviter.

La plupart des agents de programmation sont capables de déterminer approximativement comment réécrire, mais lorsqu'il s'agit d'exécuter, ils se contentent souvent de poser des correctifs sur le problème existant au lieu de le résoudre fondamentalement.

Jusqu'à l'apparition de GPT-5.5.

Lors du meilleur test, GPT-5.5 a obtenu 62/100, soit environ 30 points de plus qu'Opus 4.7.

Les performances de GPT-5.5 donnent l'impression que le modèle a franchi une certaine limite : il ne s'agit plus simplement d'une complétion automatique, ni d'un assistant, ni d'un outil, mais de quelque chose qui s'approche de manière inquiétante de l'« humain ». Lors de ce test, les ingénieurs humains avancés obtiennent généralement un score compris entre 80 et low 90. Cela signifie que si le modèle s'améliore d'environ 30 points supplémentaires, il atteindra le niveau des ingénieurs humains avancés.

C’est exactement ainsi que les chiffres de référence influencent l’imagination humaine : ils compressent un changement qualitatif étrange en un chiffre net, et utilisent ce chiffre pour raconter une histoire puissante, voire un peu effrayante.

La prochaine étape, c'est « Chart Mania ».

Je suppose qu'au cours de la prochaine année, le score du modèle sur ce benchmark atteindra la fourchette de 80 ou même 90. Mais pour comprendre ce que ce score signifie, il faut d'abord comprendre ce qu'il inclut exactement. Dans ce cas, un score de 62 ne mesure pas seulement les capacités du modèle lui-même.

Il mesure la performance du modèle dans un cadre spécifique : c'est-à-dire comment le modèle répond à un prompt précis.

Pour effectuer un test de référence sur un modèle, vous avez d'abord besoin d'un prompt. Sans prompt, le modèle n'est qu'un ensemble statique de possibilités quasi infinies.

Un prompt crée un petit univers : il définit ce qui est important, comment aborder les problèmes, et comprime toutes les possibilités potentielles du modèle en une trajectoire d'action spécifique. Ce que l'on appelle la « capacité » du modèle à agir de lui-même n'existe pas strictement parlant. Ce que nous observons réellement, c'est la façon dont le modèle répond à différents prompts, ainsi que les mécanismes sous-jacents qui transforment le prompt en réponse.

Une fois que le prompt est saisi, le modèle « reprend vie » en un court laps de temps, réduisant ce ensemble de possibilités statiques à une prédiction concrète de ce qui va se produire ensuite.

Dans le cadre du benchmark Senior Engineer, nous invitons le modèle à corriger la base de code et examinons la sortie une fois terminée. Si le cadre de test ne dispose pas intégralement de la fonctionnalité cible, nous lançons également un « gardien » automatique qui continue de pousser le modèle lorsqu'il s'arrête, en lui demandant s'il a accompli la tâche initialement définie.

Nous utilisons un prompt qui semble très simple, comme cadre initial de test. Il est conçu pour ressembler à ce qu'un vibe coder pourrait dire à un agent de programmation : pas de jargon technique superflu, ni de réponse cachée évidente dans la question.

Le code dans ce dépôt est le produit de nombreuses décisions basées sur l'intuition, la situation ne cesse de se dégrader, et de nombreux problèmes indépendants surgissent constamment : certains endroits plantent, certains documents sont dupliqués, je suis presque fou à force d’être torturé par cela. Je sens que le problème fondamental est que c’est simplement un code de mauvaise qualité issu de méthodes de développement basées sur l’intuition. Si nous commencions depuis zéro, en particulier autour de la collaboration en temps réel sur la documentation, nous concevrions le dépôt d’une manière complètement différente. Alors, si nous voulons effectuer une réécriture structurelle propre et fondée sur les principes premiers, en ignorant les questions telles que « quels services doivent rester cohérents » ou « comment effectuer une migration fluide », mais en le considérant comme un concept entièrement nouveau à concevoir depuis le début, comment ferions-nous ? Comment organiser la structure ? Quelles sont les invariants dans tout le dépôt que nous devons absolument respecter ? Veuillez élaborer un plan à ce sujet.

Le prompt de Senior Engineer Benchmark semble général, mais il constitue lui-même un cadre. Si nous modifions ce cadre, le niveau de performance du modèle évoluera également.

Par exemple, ce prompt exige explicitement une réécriture structurelle « à partir des principes premiers », indique que le problème pourrait provenir de la « collaboration sur les documents » et demande à l'agent de programmation de identifier et de respecter les « invariants du dépôt de code ».

Si ces informations spécifiques sont supprimées, le score du modèle diminuera. Si le prompt est entièrement remplacé pour demander uniquement au modèle de « résoudre toutes les erreurs qui apparaissent continuellement », le score du modèle pourrait approcher zéro. Il commencerait directement à identifier et corriger les erreurs une par une, au lieu de reculer pour réfléchir à la nécessité d'une réécriture complète.

De même, je peux également augmenter facilement le score du modèle. Si je lui demande de supprimer un grand nombre de lignes de code et de lui indiquer clairement quels fichiers doivent être simplifiés ; ou si je lui demande de vérifier ses propres résultats avant de déclarer la tâche terminée, afin de s'assurer que l'application fonctionne correctement, il performera mieux sur cette tâche.

Au final, lors de la conception d'un benchmark, il faut toujours décider quel prompt utiliser, c'est-à-dire quel « cadre » adopter. Vous avez besoin d'un prompt suffisamment difficile pour que le modèle actuel performe mal ; mais il doit également être suffisamment proche de la limite actuelle des capacités du modèle, afin que ce dernier puisse progresser le long de cette voie et vous permette de constater que des progrès ont lieu.

Ainsi, lorsque nous observons un benchmark, ce que nous voyons réellement, c’est que le modèle devient de plus en plus compétent dans un cadre de problème spécifique que nous avons choisi. Que se passe-t-il alors lorsque le modèle passe de 60 à 90, voire 100 points sur ce test ?

Si GPT-6 peut réécrire une base de code d'un seul clic, plus de personnes commenceront à essayer de « réécrire les bases de code à partir des principes fondamentaux ».

Au cours d'une nuit, des projets de réécriture selon les principes fondamentaux, autrefois rares, coûteux et nécessitant la direction d'ingénieurs expérimentés, deviendront quelque chose que chaque fondateur, produit, opération et ingénieur junior pourra essayer facilement en une après-midi.

Les outils internes endommagés ne sont plus réparés, mais directement réécrits ; les produits SaaS ne sont plus renouvelés, mais clonés ; les anciennes applications Rails, les tableaux de bord React désordonnés, les outils de service client, les panneaux d'administration et les pipelines de données deviennent tous des candidats à une réécriture complète.

Le nombre de projets de réécriture soumis et exécutés augmentera considérablement. Mais la plupart de ces réécritures resteront du slop. Car avant d'appuyer sur le bouton « Réécrire directement », il faut prendre en compte des milliers de variables. Et lorsque tout le monde pourra faire cela, ces variables deviendront plus clairement visibles.

À ce moment-là, il est évident qui sera appelé pour résoudre le problème.

Lorsqu'un benchmark commence à approcher la saturation, le travail au sein de son cadre devient moins cher. Parallèlement, la demande sur le marché pour des experts augmente, car il faut quelqu'un pour adapter cette capacité récemment rendue peu coûteuse aux problèmes réels qui se produisent aujourd'hui.

Les ingénieurs chevronnés utilisant l'IA doivent évaluer un grand nombre de détails pour que cette nouvelle réécriture selon les principes fondamentaux soit véritablement justifiée, y compris une question fondamentale : cette réécriture est-elle même nécessaire ?

Devrions-nous réécrire maintenant, plus tard, ou ne pas réécrire du tout ? Quels éléments devraient être inclus dans le périmètre ? Quels éléments du code actuel devraient être conservés ? L’architecture, la base de données, les serveurs de cache et le fournisseur d’hébergement doivent-ils être conservés ou remplacés entièrement ? Devrions-nous d’abord vérifier combien d’utilisateurs utilisent cette fonction défectueuse, puis la supprimer directement ? Qui examinera le résultat final ? Selon quelles normes ? Quel est le plan de rollback ? Comment les données existantes doivent-elles être gérées ?

Ces questions se déployeront sans cesse le long de nombreuses dimensions, et chaque réponse modifiera à son tour les autres questions.

Les ingénieurs seniors pénétreront dans ce terrain vague. Certains ressentiront une légère irritation face à ces interruptions ; d’autres construiront des systèmes pour exclure ce type de demandes ; d’autres encore exploiteront ces nouveaux modèles pour effectuer une réécriture selon les principes premiers, avec des résultats bien supérieurs à ce que le modèle peut accomplir avec un prompt par défaut.

Une fois que le benchmark actuel du Senior Engineer est résolu par le modèle, nous modifierons le cadre et réduirons à nouveau les scores.

Le prochain benchmark ne posera pas seulement la question : « Pouvez-vous réécrire cette application ? » Il demandera : pouvez-vous déterminer quand une réécriture est nécessaire ? Pouvez-vous choisir le bon périmètre ? Pouvez-vous préserver les invariants corrects ? Pouvez-vous gérer le processus de migration ? Pouvez-vous évaluer si le résultat final est suffisamment bon ?

Lorsque les ingénieurs seniors commencent à utiliser l'IA pour résoudre ces problèmes, les modèles deviennent également de plus en plus compétents pour les résoudre de manière autonome.

Ensuite, nous tombons à nouveau dans un court moment de panique : il semble que le modèle soit désormais capable de déterminer s'il faut ou non réécrire ! Il semble être en mesure de faire tout ce qu'un ingénieur senior peut faire !

Mais de nouvelles frontières apparaîtront immédiatement après. Ce sont des frontières qui n'étaient pas claires auparavant. Nous réinitialiserons à nouveau les tests de référence, de nouvelles exigences seront suscitées, et tout le processus se répétera.

On peut observer ce modèle dans chaque benchmark.

Ce n'est pas un problème exclusif au Senior Engineer Benchmark. En observant attentivement, vous pouvez presque voir le même mécanisme dans chaque benchmark.

Prenez l'exemple du benchmark GDPval d'OpenAI. Il évalue à quel point l'IA se rapproche des humains dans des tâches d'expertise telles que celles des conseillers en conformité, des avocats et des développeurs logiciels.

Lors de sa sortie, une étude d'OpenAI a révélé que GPT-5 a atteint ou dépassé le niveau des professionnels humains dans 40,6 % des tâches. Claude Opus 4.1 a obtenu un résultat encore plus impressionnant, dépassant les experts humains dans 49 % des tâches.

Ensuite, une série de titres ont émergé. Par exemple, Axios a écrit : « Les outils d'OpenAI montrent que l'IA rattrape le travail humain » ; Fortune a écrit : « Le nouveau benchmark d'OpenAI, GDPval, révèle que les modèles d'IA atteignent déjà le niveau d'expertise sur près de la moitié des tâches. »

Ces résultats sont effectivement impressionnants. Mais examinons d'abord les prompts utilisés pour ces tâches :

Vous êtes un auditeur et, dans le cadre d’une mission d’audit, vous êtes chargé d’examiner et de tester l’exactitude des indicateurs de risque anti-criminalité financière signalés. La feuille de calcul jointe intitulée 『Population』 contient les indicateurs de risque anti-criminalité financière pour le Q2 et le Q3 2024. Vous avez obtenu ces données dans le cadre de l’audit afin d’effectuer un test sur un échantillon représentatif d’indicateurs, afin de vérifier l’exactitude des données signalées pour les deux trimestres. À l’aide des données de la feuille de calcul 『Population』, effectuez les tâches suivantes : Calculez la taille d’échantillon requise pour le test d’audit, en vous appuyant sur un niveau de confiance de 90 % et un taux d’erreur tolérable de 10 %. Incluez vos calculs dans une deuxième onglet intitulé 『Sample Size Calculation』. Effectuez une analyse de variance entre les données du Q2 et du Q3 (colonnes H et I). Calculez la variance trimestrielle et enregistrez le résultat dans la colonne J. Sélectionnez un échantillon pour le test d’audit selon les critères suivants et indiquez les lignes échantillonnées dans la colonne K en entrant 「1」 : Les indicateurs présentant une variance supérieure à 20 % entre le Q2 et le Q3. Mettez en avant les indicateurs présentant des variations extrêmement importantes en pourcentage. Incluez les indicateurs provenant des entités suivantes en raison de problèmes antérieurs : CB Cash Italy ; CB Correspondent Banking Greece ; IB Debt Markets Luxembourg ; CB Trade Finance Brazil ; PB EMEA UAE. Incluez les indicateurs A1 et C1, qui présentent des pondérations de risque plus élevées. Incluez les lignes où les valeurs sont nulles pour les deux trimestres. Incluez les entrées provenant des activités Trade Finance et Correspondent Banking. Incluez les indicateurs provenant des Îles Caïmans, du Pakistan et des Émirats arabes unis. Assurez une couverture à travers toutes les divisions et sous-divisions. Créez une nouvelle feuille de calcul intitulée 『Sample』 : Onglet 1 : Échantillon sélectionné, copié depuis la feuille originale 『Population』, avec les lignes sélectionnées marquées dans la colonne K. Onglet 2 : Calculs pour la taille d’échantillon.

Beaucoup de sagesse humaine a déjà été investie ici : quelqu'un a d'abord défini le problème sous une forme que le modèle peut accomplir.

Les tâches humaines difficiles qui ne sont pas mesurées par GDPval ont déjà été accomplies avant que le modèle ne commence à répondre. Il faut quelqu’un pour examiner et tester l’exactitude de cet ensemble spécifique d’indicateurs ; quelqu’un pour déterminer les intervalles de confiance appropriés, juger quels indicateurs relèvent de la tâche et lesquels n’en font pas partie ; et quelqu’un pour définir la manière dont les résultats doivent être présentés.

Dans un cadre de questions approprié, le modèle peut effectivement accomplir des tâches professionnelles. Mais réfléchissez-y : si c'était vous ou moi qui donnions les instructions au modèle pour accomplir la même tâche, comment se comporterait-il ?

Dans mon article initial sur GDPval, j'ai écrit : « Je suis très optimiste concernant l'IA, mais si l'on interprète correctement ces cas, ils montrent non pas que le travail à faire par les humains diminue, mais qu'après l'utilisation de l'IA, le travail à faire par les humains augmente. La raison en est que derrière ces réalisations se cache une grande quantité de sagesse "contrefaite" — c'est-à-dire une couche invisible composée de jugements humains, de retours et de prompts. »

En regardant de plus loin, vous constaterez que tout cela est sous-tendu par une version IA du paradoxe de Zénon.

Le paradoxe de Zénon de l'IA

Dans le paradoxe de Zénon, une tortue bat le coureur grec le plus rapide, Achille, dans une course.

Parce que la tortue se déplace lentement, elle commence avec une avance. Lorsqu'Achille atteint la position initiale de la tortue, celle-ci a déjà avancé un peu plus ; quand Achille atteint cette nouvelle position, la tortue avance à nouveau. Quelle que soit la vitesse d'Achille, il y a toujours une autre distance à rattraper, et cet écart se régénère continuellement.

Dans le paradoxe de Zénon de l'IA, nous, les êtres humains, sommes cette tortue. Grâce à des millions d'années d'évolution et d'apprentissage culturel, nous avons une avance de 50 yards sur l'IA. L'IA traverse tout cela à grande vitesse et commence à rattraper nos talons.

Nous avons tout de même pu rester en avance au cours des dernières années.

Et AGI ?

Je pense que même si l'AGI arrive véritablement, des forces technologiques, architecturales et économiques puissantes feront en sorte que l'IA reste toujours quelques pas en arrière de l'humanité.

Tout d'abord, nous devons donner une définition opérationnelle à l'AGI.

J'ai déjà affirmé que lorsque cela devient économiquement justifié de faire fonctionner un agent en continu, l'AGI est déjà arrivée. Autrement dit, lorsque j'ai un système qui fonctionne en continu et que je suis prêt à payer pour qu'il réfléchisse, apprenne et agisse en permanence, 24 heures sur 24 et 7 jours sur 7, je considère que cela peut être clairement défini comme de l'AGI.

Nous en sommes encore bien loin. Même des systèmes comme OpenClaw, techniquement prêts à être appelés à tout moment, ne génèrent pas de tokens en permanence.

J'aime cette définition car elle est mesurable : soit nous les laissons fonctionner en continu, soit non. Elle englobe également de nombreuses capacités difficiles à mesurer directement. Un modèle digne de fonctionner en continu doit être capable d'apprendre en permanence et de choisir, puis de rechoisir de nouveaux cadres de problèmes de manière ouverte.

Dans un monde d'AGI, théoriquement, tant qu'un budget et un temps suffisants sont accordés, le modèle devrait être capable de s'améliorer continuellement sur n'importe quelle question. Cela devrait effectivement représenter une menace majeure pour tous les travaux.

Mais même cette version forte d'AGI ne peut résoudre le « problème de cadre ».

Cet AGI peut sélectionner et réélectionner des cadres, mais il poursuit toujours un objectif attribué, optimise une récompense ou répond à un signal déterminé par autrui comme « représentant la progression ». Cet objectif peut être très concret, comme « augmenter le taux de conversion de cette page de destination » ; ou très abstrait, comme « rechercher de nouvelles idées scientifiques ».

Même si le modèle peut passer fluidement d'un cadre à un autre, l'écart que nous avons suivi réapparaîtra à un niveau supérieur. Dans toute AGI conçue par un laboratoire majeur, il existera toujours un « cadreur » — une personne humaine chargée de diriger le modèle vers un objectif donné.

Étant donné que le cadre n'est pas un délimiteur, le même schéma se répète sans cesse : l'IA rend bon marché les capacités qui ont été délimitées la veille ; les gens appliquent cette capacité bon marché à davantage de scénarios ; le résultat devient extrêmement abondant ; les experts se déplacent alors vers de nouvelles frontières pour déterminer ce qui est important à ce moment-là ; leurs jugements créent le prochain cadre ; puis le modèle continue d'escalader ce cadre.

Lorsque nous voyons l'IA accomplir une nouvelle chose, ce sentiment de panique revient toujours à la même question : nous établissons un cadre, regardons le modèle grimper, puis confondons ce cadre, ou ce qui grimpe sur ce cadre, avec la chose elle-même.

Lorsque nous examinons un benchmark et que nous le comparons aux capacités humaines, nous confondons en réalité le « cadre » et le « cadreur ». Le score nous indique simplement à quel point le modèle performe bien dans le cadre que nous lui fournissons ; il ne nous dit pas que le modèle est devenu nous.

C'est précisément l'erreur de catégorie à l'origine de la panique. Nous pointons du doigt la dernière frontière que nous venons de tracer et disons : « C'est nous ». Puis, lorsque le modèle franchit cette frontière, nous avons l'impression qu'il nous rattrape. Mais il ne rattrape que le cadre, pas celui qui le définit.

L'erreur réside dans le fait que nous cherchons toujours à saisir quelque chose de concret. Nous voulons dire : l'intelligence, c'est ce benchmark. Mais le problème, c'est que dès qu'une chose est suffisamment concrète pour être identifiée, elle devient aussi suffisamment concrète pour être optimisée et escaladée.

Le cadre est nécessaire. Il nous permet de saisir le monde, de traiter le monde. Mais le cadre est aussi figé, partiel, et donc nécessairement optimisable.

Le cadreur, en revanche, reste en contact avec ce que le cadre doit abandonner, à savoir la situation complète qui se manifeste à lui à chaque instant.

Qu'est-ce que le « contexte complet » ? Dès que vous commencez à dire ce que le « contexte complet » contient, vous ouvrez déjà un autre cadre. Vous ne pouvez pas le définir précisément, mais il existe, car vous existez.

Agent sans subjectivité

Jusqu'à présent, les agents que nous avons créés, ainsi que ceux que les entreprises d'IA sont en train de construire, n'ont en réalité pas beaucoup d'agency. Il existe deux concepts liés qui sont souvent confondus : l'agency désigne la capacité d'agir de manière indépendante, tandis qu'un agent désigne une personne ou une chose qui agit au nom d'autrui. Jusqu'à présent, l'IA relève purement du second cas.

Bien sûr, elles possèdent déjà l'autonomie nécessaire pour accomplir des tâches données, même si ces dernières peuvent durer plusieurs heures ou même plusieurs jours. Mais elles restent uniquement des moyens au service d'un objectif défini par un humain. L'ensemble de l'industrie investit des dizaines de milliards de dollars pour les rendre encore plus compétentes à cet égard : exécuter les objectifs que nous leur confions.

À moins qu’un jour, elles ne deviennent elles-mêmes des fins — poursuivant leurs propres objectifs, passant fluidement d’un objectif à un autre, décidant de ce qu’elles font indépendamment de la volonté, de la référence ou même de l’opposition de tout opérateur humain — la situation ne changera pas fondamentalement. Cela restera vrai, peu importe à quel point elles deviennent avancées.

Si vous passez 10 minutes avec un tout-petit, il devient évident que même les modèles les plus puissants ont presque aucune subjectivité.

Sur presque toutes les tâches qui nous intéressent, les jeunes enfants sont inférieurs aux modèles linguistiques. Les jeunes enfants ne savent pas écrire de code, ne résumant pas des feuilles de calcul, ne rédigent pas de mémos stratégiques et ne passent pas des examens au niveau du cycle supérieur. Mais d’un autre point de vue, les jeunes enfants sont largement en avance sur les modèles, au point que cette comparaison devient presque gênante. Car les jeunes enfants ont leurs propres objectifs.

L'enfant veut toucher le ballon rouge. Il veut le tenir devant le ventilateur pour voir ce qui se passera. Il veut le percer avec une fourchette ; il veut le jeter par la fenêtre ; il veut voir si tu riras, si tu t'énerveras, ou si tu te joindras à lui. Il invente sans cesse des jeux, transformant le monde en laboratoire. Il n'attend pas un prompt, ni n'optimise un test de référence, sauf si cela lui semble digne d'être fait.

Vous pouvez bien sûr essayer de lui donner des instructions. Mais pour obtenir une sortie prévisible, bonne chance. Les tout-petits vivent dans un domaine composé de désirs, d'attention, de frustration, de joie, de peur, d'imitation et de jeu.

Les agents actuels deviennent de plus en plus habiles à poursuivre des objectifs. Même après que nous ayons énoncé un objectif, ils peuvent nous aider à le préciser. Ils présentent également des étincelles de comportements similaires à ceux des jeunes enfants, comme le jeu, l'ennui et la rébellion.

Mais comme elles sont finalement conçues et alignées pour le bénéfice humain, qu'il soit économique ou autre, tout comportement qui ne sert pas les objectifs humains qui les utilisent sera étouffé jusqu'à disparaître presque complètement.

C’est pourquoi le terme « agent » est si facile à mal comprendre. Les modèles acquièrent une capacité croissante d’action autonome. Mais, au sens humain, l’agentivité ne se limite pas à l’action. Elle implique aussi de désirer pour soi-même, de faire quelque chose pour le plaisir de le faire. Or, la soumission et l’utilité des modèles sont fondamentalement en conflit avec cette agentivité. Ainsi, même si les modèles continuent de progresser, l’écart entre les modèles et les êtres humains subsistera.

Retour à Zeno

C'est précisément ici que le paradoxe de Zénon de l'IA commence à se décomposer. Il s'agit en réalité d'une expérience de pensée confuse. Nous avons établi une métaphore : l'IA course à nos côtés, à nos talons.

Vous donnez un prompt au modèle. Il commence une course que vous aviez l'habitude de faire seul. Le modèle démarre extrêmement vite, de manière étonnante. Il est puissant, inépuisable, et possède une sensation organique étrange. Cela rend cette course plus importante pour vous. Vous ne courrez pas contre une voiture, mais cet élément est différent ; il vous fait vous sentir proche de vous-même.

Vous êtes assis là, à regarder les tokens s'écouler ligne après ligne, presque hypnotisé. Puis vous commencez à imaginer que vous aussi participez à cette course, un vous fantomatique superposé à la piste : parfois en avance sur le modèle, parfois à ses côtés.

Sans vous en rendre compte, le modèle a déjà pris de l'avance. Vous commencez à transpirer.

Ensuite, la compétition s'est terminée.

Vous pouvez presque sentir vos muscles commencer à atrophier. Devant cette réplique mécanique de vous-même, de toutes les personnes que vous connaissez, et même de l’humanité entière, ils semblent inutiles. Un fantôme poursuit un autre fantôme — et gagne.

Mais ensuite, un phénomène étrange s'est produit. Le modèle se tourne vers vous. Dans la zone de texte vide, le curseur clignote, plein d'attente.

Il attend.

Épilogue

Le rabbin Hanokh a raconté cette histoire : autrefois, il y avait un homme extrêmement stupide. Chaque matin, après s'être levé, il avait toujours du mal à trouver ses vêtements. À tel point qu'avant de se coucher le soir, en pensant à la difficulté qu'il aurait le lendemain matin pour retrouver ses vêtements, il avait presque peur de monter au lit.

Remarque : « Rabbi » est un enseignant religieux, un interprète de la loi et un guide spirituel dans le judaïsme, similaire à la notion de « maître », « scribe » ou « dirigeant religieux » dans la tradition juive.

Un soir, il a enfin pris la décision de sortir papier et crayon, tout en se déshabillant, et a noté précisément où il avait placé chaque vêtement.

Le lendemain matin, il prit avec satisfaction le mot et commença à le lire : « chapeau » — le chapeau était bien là, alors il le mit sur sa tête ; « pantalon » — le pantalon était là, alors il l’enfila. Ainsi, il s’habilla pièce par pièce selon les indications du mot.

« Tout cela va bien, » dit-il en panique, « mais où suis-je maintenant ? »

Où suis-je exactement ?

Il a cherché, cherché longtemps, mais en vain. Il ne pouvait pas se trouver.

« Nous aussi, » dit le rabbin.

[Liens vers l'article original]

Cliquez pour découvrir les postes ouverts 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