En 2020, GPT-3 pouvait terminer votre phrase par quelque chose qui sonnait plausible. En 2026, Sol d’OpenAI peut coordonner une équipe de ses propres sous-agents sur une tâche de codage de plusieurs heures, et Fable d’Anthropic peut rivaliser avec lui sur les benchmarks les plus difficiles du domaine. C’est un vrai bond en avant : d’un modèle qui prédisait le mot suivant à un système qui planifie, délègue et vérifie son propre travail.
Voici la partie dont on ne parle pas assez. Pendant que les modèles faisaient ce bond, la relation de la plupart des gens avec eux a à peine bougé.
Une étude menée par OpenAI avec l’économiste de Harvard David Deming, basée sur plus d’un million de conversations réelles, a révélé que près de 80 % de l’usage de ChatGPT se répartit encore en trois catégories : rédaction, recherche d’information et conseils pratiques. Le codage — précisément la frontière où Sol et Fable se disputent la tête sur les benchmarks — représente environ 4 % des messages. Pour la plupart des utilisateurs, un modèle conçu pour exécuter des flux de travail agentiques autonomes est utilisé comme les gens utilisaient Google en 2015 : poser une question, obtenir une réponse, passer à autre chose.
La vraie histoire de l’ère GPT-3 à Sol/Fable n’est pas que les modèles sont devenus plus intelligents. C’est que l’écart entre ce qu’ils peuvent faire et ce que nous leur demandons de faire n’a jamais été aussi large.
Cet écart mérite qu’on s’y attarde, car il va à l’encontre du récit habituel. Le récit habituel dit que l’IA nous distance et que nous courons pour rattraper le retard, que les emplois disparaissent, que les flux de travail s’automatisent du jour au lendemain. Les données racontent une histoire plus tranquille. Les gens intègrent ces modèles dans leur vie quotidienne, mais surtout en surface. L’usage non professionnel est passé de 53 % à plus de 70 % de toutes les conversations en l’espace d’un an, ce qui en dit long sur le caractère personnel qu’a pris cette technologie. Cela en dit beaucoup moins sur le fait que les gens l’utilisent pour faire quelque chose qu’ils ne pouvaient pas faire avant.
Quelques évolutions expliquent ce qui a réellement changé, et ce qui n’a pas changé.
La capacité est passée de la prédiction de texte en un seul passage à l’exécution agentique. GPT-3 n’avait aucune mémoire de ses propres actions et aucune capacité à utiliser des outils. Le mode phare de Sol peut faire tourner des flux de travail parallèles et agir sur les résultats sans humain dans la boucle à chaque étape. C’est un changement catégoriel, pas incrémental.
Les schémas d’usage ont beaucoup moins bougé que la capacité. La même étude du NBER a constaté que le mix rédaction / conseils / recherche d’information est resté remarquablement stable, même si le modèle sous-jacent est devenu radicalement plus capable en dessous. Les gens ne rejettent pas la nouvelle capacité. Pour la plupart, ils ignorent qu’elle existe, ou n’ont pas trouvé de raison de s’en servir.
La croissance qui a eu lieu était personnelle, pas professionnelle. Davantage de gens demandent à ces modèles des conseils, des brouillons et des explications dans leur vie quotidienne. Proportionnellement moins nombreux sont ceux qui leur confient le genre de travail lourd et à étapes multiples que ces modèles sont désormais réellement conçus pour accomplir.
Rien de tout cela ne signifie que les gens utilisent mal l’IA. L’aide à la rédaction et les réponses rapides sont des usages légitimes et précieux, et le surplus qu’ils procurent aux consommateurs se chiffre en dizaines de milliards de dollars. Mais cela signifie que la conversation sur l’impact de l’IA s’est trompée de sens sur le goulot d’étranglement. Nous n’arrêtons pas de demander si les modèles sont prêts pour des tâches plus grandes. La question la plus utile est de savoir si nous avons remarqué qu’ils le sont déjà.
Les modèles n’ont pas arrêté d’évoluer. Nous avons arrêté de poser de nouvelles questions.
Cinq cents bâtisseurs ont passé deux jours à The Brewery, à Londres (1er-2 juin), à se poser une question inconfortable : qu’est-ce que le développement logiciel, une fois que les agents font la majorité de la frappe ?
Le récit conventionnel des dix-huit derniers mois ressemble à un succès. L’agent échafaude une fonctionnalité en quelques minutes. La démo fonctionne. La direction est impressionnée. Les équipes rapportent des gains de productivité individuelle qui auraient semblé absurdes en 2023. Et c’est exactement là que la plupart des organisations se sont arrêtées.
Guy Podjarny, le fondateur de Tessl qui organise la conférence, a formulé le tournant : 2025 a été l’année où les agents de codage ont montré un vrai potentiel ; 2026 est l’année où l’on découvre s’ils tiennent la route en production — à travers les équipes, les bases de code et les environnements, sans correction humaine constante. La question utile n’est plus « l’agent peut-il le faire ? ». C’est « pouvons-nous gouverner ce que fait l’agent, à la vitesse à laquelle il le fait ? ».
Le goulot d’étranglement s’est déplacé de l’écriture du code vers sa gouvernance — et l’industrie reconstruit désormais toute la pile logicielle autour d’une nouvelle unité : la compétence (« skill »).
Quatre thèmes ont traversé les deux journées.
Les « skills » deviennent l’unité du logiciel — sans aucune de ses infrastructures. Une « skill » est un ensemble d’instructions réutilisable et versionné pour un agent, et la thèse qui traversait la conférence était que ces artefacts, et non les fichiers source, sont en train de devenir ce que les équipes rédigent, partagent et dont elles dépendent. Le problème : nous avons recréé les débuts de la programmation sans aucun de ses filets de sécurité. Il n’existe pas d’analyse statique mature pour les « skills », pas de discipline de test (les évaluations en sont l’équivalent embryonnaire), pas de gestion de dépendances, pas d’observabilité. Liran Tal, de Snyk, a rendu l’écart concret dans la présentation au titre le plus réussi de l’événement : « Votre agent a installé un malware parce qu’un SKILL.md le lui a dit. » Une « skill » est une confiance exécutable. Presque personne ne l’audite aujourd’hui.
L’ingénierie du harnais, c’est la livraison de contexte. Ryan Lopopolo, d’OpenAI, a soutenu que les contraintes structurantes du développement logiciel ont changé : ce sont désormais le temps humain, l’attention humaine et celle du modèle, et la fenêtre de contexte. Sa prescription était d’arrêter d’espérer que le modèle infère vos exigences non fonctionnelles, et de les encoder plutôt dans le harnais — les surfaces de relecture, les portes d’approbation et les pipelines de contexte autour de l’agent. Pensez au harnais comme à un gabarit d’usine : le jugement de l’artisan, coulé dans l’outillage, pour que chaque passage en hérite.
Les agents n’apprennent pas, donc la mémoire devient architecture. Lamis Mukta, d’Anthropic, a nommé la faille discrète du rêve agentique : l’intelligence ne se compose pas. La tâche cinquante commence aussi ignorante que la tâche une. La réponse de l’industrie est une progression — des fichiers d’instructions statiques aux outils de mémoire, puis aux « skills », puis à la mémoire gérée par l’agent, y compris des processus de consolidation hors ligne qu’elle a décrits comme du « rêve ». La question la plus incisive du public de la conférence a tranché dans le vif : à quel moment réinventons-nous les bases de données à partir de zéro ? La réponse honnête semblait être : nous le faisons déjà, et nous devrions au moins le faire délibérément.
L’humain est désormais le point de congestion. Birgitta Böckeler, de Thoughtworks, a clos l’événement en nommant la crise de flux : les agents génèrent du code plus vite que les humains ne peuvent le relire, et les vrais coûts se trouvent au-delà des tokens — dans la « taxe du harnais » que chaque outil impose, et dans l’énergie humaine. Don Syme, de GitHub Next, a offert à l’industrie une polarité utile : le battage médiatique vit dans la productivité individuelle, mais le problème non résolu est la continuité de l’équipe et du cycle de vie logiciel — ce sur quoi GitHub mise avec les flux de travail agentiques et « l’IA continue ». Dana Lawson, de Netlify, a ajouté le prisme du design : les plateformes ont désormais besoin d’AX, l’expérience agent, aux côtés de l’UX et de la DX, parce que la moitié des utilisateurs de vos API seront bientôt non humains. La ressource rare, a-t-elle soutenu, n’est plus la vitesse de frappe. C’est le goût, le jugement et l’architecture.
La preuve la plus concrète que ce n’était pas de la théorie de circuit de conférences est venue de ReCinq et Odevo, une entreprise de gestion immobilière de 14 000 personnes en train de se restructurer pour devenir « AI-native » — avec Ian Thomas, de Meta, décrivant la même réorganisation à l’échelle d’une organisation d’ingénierie.
Pour un chef d’équipe, le diagnostic s’écrit de lui-même. Combien des instructions que suivent vos agents ont été relues comme vous relisez du code ? Pouvez-vous nommer qui a rédigé les « skills » de votre pipeline — et remarqueriez-vous si l’une d’elles changeait ? Quand vos agents doubleront leur production le trimestre prochain, qu’adviendra-t-il de votre file de relecture ? Si l’une de ces réponses vous fait grimacer, le message de la conférence s’adressait à vous.
Faire fonctionner un agent, c’est une démo. Faire en sorte que mille passages soient d’accord entre eux, c’est de l’ingénierie.
D’après l’AI Native DevCon 2026 (Tessl), The Brewery, Londres, 1er-2 juin 2026. Les plus de 40 présentations sont disponibles à la demande sur tessl.io/devcon.
Les équipes évaluent fréquemment les fournisseurs de cloud GPU en construisant des tableurs comparant les tarifs horaires entre plateformes comme Modal, RunPod et Hugging Face Endpoints. Si cette approche paraît rigoureuse, elle passe souvent à côté de la question fondamentale : cette charge de travail devrait-elle seulement tourner sur une infrastructure GPU dédiée ?
L’article soutient que « classer les prix des GPU répond à une question que la plupart des équipes ne se posent jamais à voix haute : cette charge de travail devrait-elle être sur un GPU dédié, pour commencer ? » La réalité est que le volume et le calendrier — pas la tarification du fournisseur — devraient piloter la décision d’infrastructure.
Les coûts matériels sont visibles et faciles à comparer dans des tableurs, tandis que les schémas d’usage réels restent cachés. Ce biais de visibilité pousse les équipes à optimiser pour des métriques mesurables, aboutissant parfois à une infrastructure coûteuse qui sert un travail qui pourrait tourner à moindre coût sur des alternatives moins chères.
En dessous de 50 millions de tokens par mois : les API de modèles ouverts proposées par des fournisseurs comme DeepInfra, Together et Fireworks offrent une tarification au token d’environ « 0,03 à 0,04 $ par million » pour les grands modèles. Même la location de GPU grand public dépasse ces coûts, ce qui fait des API le choix rationnel pour les applications à faible volume.
Charges de travail en batch : les tâches de pipeline quotidiennes bénéficient de locations de GPU spot (environ 1 $ de l’heure) qui s’arrêtent une fois la tâche terminée, coûtant 30 à 90 $ par mois — moins cher à la fois que l’équivalent au token et qu’une infrastructure permanente.
Trafic soutenu à haut volume : quand l’utilisation dépasse 40 à 50 %, les GPU réservés deviennent économiques. Un H100 à « 2 $ de l’heure » faisant tourner des moteurs optimisés comme vLLM peut servir des milliards de tokens par mois pour environ 1 500 $ — battant la tarification au token à grande échelle.
Quatre situations qui priment sur tout le reste :
La conclusion est directe : « Comptez vos tokens avant de compter vos GPU. »
Chaque entreprise qui construit avec l’IA finit par affronter la même bifurcation d’achat : payer un fournisseur pour chaque unité de travail d’IA (tarification au token, comme un compteur de taxi), ou louer du matériel informatique dédié à l’heure et faire tourner un modèle ouvert soi-même (comme la location d’une voiture). Le débat se règle d’habitude à l’opinion. Nous l’avons réglé avec des factures.
Nous avons pris deux modèles d’IA librement disponibles — un petit, un 50 fois plus grand — et déployé chacun sur du matériel GPU loué en un seul après-midi, sur une plateforme qui facture à la seconde et ne fait rien payer à l’inactivité. Nous avons ensuite fait passer environ 345 000 requêtes réelles à travers eux, dans un test contrôlé et reproductible, et comparé les coûts et vitesses obtenus à ceux des principaux fournisseurs au token servant les mêmes modèles. Budget de recherche total : environ 18 $.
1. C’est votre schéma de trafic — pas le modèle, pas le fournisseur — qui décide quelle option est la moins chère. La même heure de matériel loué a traité 122 000 requêtes un jour et 57 000 le lendemain. La seule différence : les requêtes du premier jour étaient répétitives, et l’infrastructure d’IA moderne reconnaît et réutilise le travail répété. Voici le piège commercial : les fournisseurs au token vous facturent plein tarif pour du travail réutilisé. Quand vous louez la machine, cette efficacité est votre économie ; quand vous payez au token, c’est la marge de votre fournisseur. Les entreprises dont les charges de travail d’IA sont répétitives — traitement de documents sur modèle fixe, extraction standardisée, assistants aux instructions fixes — paient systématiquement trop cher avec la tarification au token, et la plupart n’ont jamais mesuré de combien. Dans notre test, la différence était de 2,2x.
2. Les gros modèles ne sont plus proportionnellement plus coûteux à faire tourner. Notre modèle 50 fois plus grand, sur du matériel plus récent, coûtait le même prix par unité de travail que le petit — et trois fois moins par requête. L’intuition selon laquelle « les modèles sérieux exigent des budgets sérieux » est de plus en plus dépassée. Concrètement, cela signifie que des montées en capacité qui semblaient prohibitives sous les hypothèses de l’an dernier sont peut-être déjà abordables. Les hypothèses méritent une mise à jour, pas un renouvellement.
3. Aucune des deux options ne gagne absolument — et le chiffre décisif tient sur un post-it. Les plus gros fournisseurs au token mutualisent la demande de milliers de clients, atteignant une efficacité qu’aucune entreprise seule ne peut égaler. Face à leurs paliers les moins chers, louer du matériel n’atteint jamais le seuil de rentabilité. Mais face aux paliers premium — ceux vendus pour la vitesse et la fiabilité, jusqu’à 8 fois le prix — notre machine louée atteignait le seuil de rentabilité à 45 % d’utilisation et offrait des temps de réponse plus constants, avec zéro interruption pour limite de débit et zéro réponse corrompue (la route API standard a échoué 7 fois sur 300 dans notre test comparatif). Le chiffre décisif est simple : ce que votre volume mensuel d’IA coûterait au token, divisé par le prix de location du matériel. Votre équipe peut le calculer en une heure. Nous avons publié la méthode complète, gratuitement, pour qu’elle puisse le faire.
Trois questions pour votre prochaine revue de budget IA :
Il existe aussi une dimension stratégique que l’argent ne capture pas : faire tourner ses propres modèles signifie que vos données restent dans une infrastructure que vous contrôlez, que votre capacité ne peut pas être limitée pendant votre heure la plus chargée, et que votre fournisseur ne peut pas changer discrètement le modèle derrière votre produit. Ces risques apparaissent rarement dans les comparaisons de coûts. Ils sont apparus dans la nôtre.
L’époque où l’auto-hébergement de l’IA exigeait une équipe d’infrastructure est révolue — toute notre évaluation tenait en une commande à déployer et 18 $ à dépenser. La question n’est plus de savoir si votre organisation peut comparer les deux options. C’est de savoir si elle l’a fait.
D’après le benchmark de terrain de CognitX, juillet 2026 : deux modèles ouverts, trois heures de GPU, ~345 000 requêtes, méthodologie complète et données publiées dans l’article référencé.
La même heure de GPU, le même modèle, la même tâche : 122 733 requêtes un après-midi, 56 987 le lendemain. Rien n’a changé dans l’infrastructure. Seul le trafic a changé.
Toute équipe qui construit sur des modèles ouverts finit par affronter la même bifurcation : payer un fournisseur au token, ou louer un GPU à l’heure et servir le modèle soi-même. Le débat tourne d’habitude sur les mauvaises variables — qualité du modèle, fonctionnalités de la plateforme, préférence pour un fournisseur. Nous avons donc arrêté de débattre et avons mesuré.
Notre dispositif était délibérément simple. Les nouveaux « Auto Endpoints » de Modal déploient un modèle ouvert derrière une API compatible OpenAI en une seule commande, facturée à la seconde d’utilisation du GPU, avec mise à zéro à l’inactivité. Nous avons déployé deux modèles aux extrémités opposées de l’échelle — Gemma 4 E2B (un modèle de classe 2B sur un A100, ~2,50 $/heure) et GPT-OSS-120B d’OpenAI (117 milliards de paramètres, sur un B200 à 9 $/heure) — et fait tourner chacun sur un protocole identique d’une heure : cinq minutes à concurrence 1 pour mesurer ce que ressent un utilisateur unique, quinze minutes à concurrence 16 pour simuler un pipeline réaliste, quarante minutes à concurrence 48 pour trouver le plafond. La tâche était une classification de sentiment avec sortie JSON strictement typée — intentionnellement facile, car nous testions l’infrastructure et son économie, pas l’intelligence du modèle. Une variable à la fois.
Cinq expériences. Environ 345 000 requêtes. Dépense totale : environ 18 $.
Ce que nous avons trouvé : savoir si l’auto-hébergement bat l’API n’est ni une question de modèle, ni une question de plateforme. C’est une question de trafic — à quel point vos prompts se répètent, à quel point votre volume est lourd, et à quel point il est régulier.
Notre premier run a fait tourner en boucle un ensemble fixe de 48 textes pendant une heure et a complété 122 733 requêtes. Nous avons ensuite refait la même heure à l’identique, avec un seul changement : chaque requête portait un document unique. Le débit est tombé à 56 987 — une chute de 2,2x, sur le même GPU, le même modèle, la même configuration.
Le mécanisme est la mise en cache de préfixe. Les moteurs d’inférence modernes mettent en cache le calcul des préfixes de prompt répétés ; les métriques du moteur lui-même montraient un taux de succès de cache de 92 % lors du premier run, et de 8 à 11 % lors du second (juste le prompt système partagé). Quand votre trafic se répète — instructions partagées, extraction sur modèle fixe, RAG sur un corpus stable — la plupart de vos « tokens d’entrée » ne coûtent presque rien au GPU.
Voici pourquoi cela compte commercialement : les API au token vous facturent la même chose pour un token en cache et un token calculé. Quand vous louez le GPU, le dividende de mise en cache est le vôtre ; quand vous payez au token, c’est la marge de votre fournisseur. Une équipe dont le trafic est répétitif à 90 % et une équipe qui traite des documents uniques achètent des quantités de calcul complètement différentes — et seul un des deux modèles de tarification le leur permet de voir.
L’intuition dit qu’un modèle 50 fois plus gros coûte bien plus cher à exécuter. Nos factures disent le contraire. Le modèle à 120 milliards de paramètres sur le B200 a délivré 3,7 fois le débit du modèle à 2 milliards sur l’A100 — 33 000 contre 8 900 tokens par seconde sur des documents uniques — pour 3,6 fois le prix horaire. Le coût par million de tokens ressort quasiment identique : 0,076 $ contre 0,078 $. Le coût pour mille requêtes chute d’un facteur trois, à environ quatre centimes et demi.
Deux facteurs ont absorbé tout le saut d’échelle : la conception en mélange d’experts du modèle n’active que 5,1 milliards de ses 117 milliards de paramètres par token, et la génération de GPU plus récente apporte bien plus de bande passante mémoire par dollar. Nous présentons ceci comme un résultat mesuré pour cette paire précise, pas comme une loi générale — un modèle dense de 70 milliards raconterait une histoire différente. Mais cela brise un réflexe qui mérite de l’être : ne tarifez pas un modèle par son nombre de paramètres.
Voici maintenant le résultat qu’un benchmark sponsorisé par un fournisseur enterrerait. À notre meilleur débit mesuré, le coût effectif du modèle à 120B auto-hébergé était de 0,076 $ par million de tokens. Les tarifs API les moins chers des hyperscalers pour ce même modèle se situent autour de 0,04 $ en entrée et 0,14–0,18 $ en sortie — ce qui signifie que, pour un trafic de documents uniques, ces fournisseurs battent notre GPU unique même si nous le maintenions saturé à 100 % du temps. Le seuil de rentabilité n’arrive jamais. La raison est structurelle : un fournisseur qui regroupe les requêtes de milliers de clients atteint une utilisation qu’aucun locataire unique ne peut égaler, et un seul GPU ne peut pas surpasser une flotte en mutualisation.
Mais « l’API » n’est pas un prix unique. Les tarifs pour ce même modèle s’étalent sur une fourchette d’environ 8x entre les fournisseurs hyperscale en batch et les paliers premium à faible latence. Face au palier rapide (0,15 $ en entrée / 0,75 $ en sortie par million), notre B200 atteignait le seuil de rentabilité à 31–45 % d’utilisation et l’emportait nettement au-delà. Et sur du trafic répétitif — le régime de mise en cache — l’option auto-hébergée battait la majorité du marché, sans conteste.
La carte honnête comporte donc trois régions. Documents uniques à volume modéré : achetez des tokens auprès d’un fournisseur hyperscale. Trafic répétitif à haut volume, ou charges de travail actuellement facturées aux paliers API premium : le GPU horaire l’emporte. Tout le reste : cela dépend d’un chiffre que vous pouvez calculer à l’avance — l’utilisation au seuil de rentabilité : le prix horaire de votre GPU divisé par ce que coûterait votre volume horaire de tokens à l’API. Le nôtre allait de 0,31 (l’auto-hébergement gagne facilement) à 1,86 (il ne peut pas gagner).
Une précision sur le périmètre : notre charge de travail était composée à 98 % de tokens d’entrée — de la classification sur documents. Les charges de travail orientées sortie, comme le chat ou la rédaction, modifient le calcul des deux côtés, ce qui est exactement pourquoi vous devriez faire tourner ce calcul sur votre propre mix de trafic. Les prix de cet article vieilliront ; cette division, non.
Le coût n’est que la moitié de la bifurcation ; l’autre moitié est la vitesse. Nous avons donc fait tourner une dernière comparaison côte à côte : 300 requêtes identiques à concurrence 1, depuis la même machine, contre notre B200 auto-hébergé et contre le même modèle sur le marché des API via OpenRouter — une fois en laissant le routeur choisir le fournisseur, une fois épinglé sur le palier le moins cher (DeepInfra), une fois épinglé sur le plus rapide (Groq).
| Bout en bout, c=1 | p50 | p95 | p99 | Échecs |
|---|---|---|---|---|
| B200 auto-hébergé | 0,35 s | 0,47 s | 0,57 s | 0 |
| Groq (palier premium) | 0,31 s | 0,85 s | 1,29 s | 2 (limites de débit) |
| DeepInfra (palier bon marché) | 0,98 s | 2,36 s | 4,01 s | 0 |
| Choix du routeur | 1,24 s | 4,37 s | 6,16 s | 7 |
Trois éléments de ce tableau méritent une relecture de contrat. Premièrement, le palier premium a battu notre médiane de 44 millisecondes — et a perdu partout ailleurs : notre p95 était presque deux fois meilleur, notre p99 était 2,3 fois meilleur, notre gigue quatre fois plus serrée, et nous n’avons jamais été limités en débit. La tenance dédiée ne vous achète pas la médiane la plus rapide ; elle vous achète une queue de distribution qui existe à peine, et la latence de queue est ce que les utilisateurs ressentent réellement. Deuxièmement, « l’API » telle que la plupart des utilisateurs la consomment — la route par défaut — est une loterie : nos requêtes ont été servies par treize fournisseurs différents dont les médianes individuelles s’étalaient de 0,29 à 5,08 secondes, une fourchette de 17x derrière un seul point d’entrée.
Troisièmement, une découverte fortuite que nous considérons comme le risque le plus sous-estimé de ce marché : chacun des sept échecs sur la route par défaut était une réponse de sortie structurée malformée, et les sept provenaient d’un seul fournisseur — un taux d’échec de schéma de 32 % sur les requêtes qu’il a servies, contre zéro réponse malformée sur nos 345 000 requêtes auto-hébergées. La fiabilité de la sortie structurée est une propriété du fournisseur, et aucune page tarifaire ne le mentionne.
Notez la symétrie avec l’économie : le seul palier API qui égale la vitesse d’un GPU dédié est le palier premium — précisément celui que notre seuil de rentabilité indique comme battu par l’auto-hébergement dès 45 % d’utilisation. Plus votre produit dépend de la latence, moins vous êtes en concurrence avec le plancher du marché des API, et meilleur le GPU horaire paraît.
Trois faits opérationnels tirés de nos journaux, parce qu’un rapport de terrain vous doit la friction. Les démarrages à froid allaient de quatre à neuf minutes sur quatre démarrages — une variance de 2x — l’essentiel provenant de l’initialisation du moteur et de la capture de graphes CUDA, pas du chargement des poids — ce qui rend la mise à zéro impropre aux charges de travail interactives sans stratégies de préchauffage. Sous surcharge soutenue avec des documents uniques, la recette de service du petit modèle a planté et s’est auto-réparée, coûtant huit minutes de disponibilité en cours de run ; la configuration à 120B a traité 164 641 requêtes avec une seule erreur. Et sur l’ensemble des 344 000 requêtes, la sortie JSON strictement typée n’a jamais produit une seule réponse malformée — la sortie structurée au niveau du moteur est, dans notre expérience, prête pour la production.
Rien de tout cela n’apparaît dans la tarification au token, et tout cela est apparu dans nos trois premières heures de GPU. Cette asymétrie est l’argument le plus profond en faveur du test : le modèle horaire vous montre le comportement réel de votre système — ses caches, ses plafonds, ses modes de défaillance — parce que vous possédez la pile de service qui le produit.
Notre protocole complet — sondage, charge par phases, comptage des tokens, calcul du seuil de rentabilité — est une paire de scripts Python que nous avons publiés en open source. L’exécuter sur votre propre point de terminaison coûte à peu près le prix d’un déjeuner.
L’API vous vend des tokens. Le GPU vous vend une heure. Lequel est le moins cher est écrit dans votre trafic, pas sur leur page tarifaire.
Benchmarks : Modal Auto Endpoints, juillet 2026 — Gemma 4 E2B-it (1×A100-40GB, 2,50 $/h) et GPT-OSS-120B (1×B200, 9 $/h), recettes SGLang, us-west, un seul conteneur, protocole identique en 3 phases. Prix API de référence issus des tarifs publics des fournisseurs, juillet 2026. Comparaison de latence : 300 requêtes par cible à concurrence 1 via OpenRouter (auto, épinglé DeepInfra, épinglé Groq), même client et même charge utile ; le nombre de tokens de complétion variait selon le fournisseur (19-35 tokens), les contrôles de raisonnement étant honorés différemment. Données complètes par requête et scripts disponibles dans le dépôt référencé.
METR a mené un essai contrôlé randomisé de février à juin 2025, examinant les effets des outils d’IA sur du travail réel :
Le protocole de l’étude comportait un élément important : avant la randomisation, les développeurs prédisaient le temps d’achèvement de chaque problème, à la fois avec et sans assistance de l’IA. Cette double prévision servait de référence de difficulté indépendante de l’assignation au traitement, et capturait les attentes de départ. Le résultat mesuré — le temps d’achèvement réel — était établi avant le traitement, empêchant l’IA de gonfler les métriques par de la verbosité ou une fragmentation artificielle des tâches.
Trois comparaisons essentielles révèlent le cœur du constat :
| Groupe | Impact attendu de l’IA |
|---|---|
| Experts en économie | accélération de 39 % |
| Experts en ML | accélération de 38 % |
| Développeurs, avant l’étude | accélération de 24 % |
| Développeurs, après l’étude | accélération de 20 % |
| Résultat réel | ralentissement de 19 % |
L’erreur de direction était systématique dans tous les groupes de prévision. Fait le plus frappant : les développeurs ont terminé l’étude convaincus que l’IA avait accéléré leur travail de 20 %, alors que les mesures montraient l’inverse. Fait intéressant, les développeurs ont montré des prévisions précises sur la durée des tâches elle-même (corrélation d’environ 0,6 avec les temps réels), mais leur évaluation de la contribution spécifique de l’IA était inversée.
L’analyse de 143 heures d’enregistrements d’écran, à une granularité de 10 secondes, a révélé que lorsque l’IA était disponible, les développeurs passaient moins de temps à écrire et à chercher du code. Ils consacraient à la place des heures supplémentaires à « la formulation des prompts, l’attente de la génération, l’évaluation du résultat » — et, fait notable, les périodes d’inactivité augmentaient. L’outil a redistribué le travail plutôt que de l’éliminer, créant un échange défavorable entre le temps de codage et les activités de supervision.
L’examen de 21 mécanismes potentiels a identifié quatre regroupements catégoriels. Cinq facteurs ont montré une contribution significative au ralentissement :
Six facteurs ont montré des indices allant à l’encontre d’une contribution au ralentissement, tandis que dix sont restés non concluants. Les chercheurs ont reconnu ne pas pouvoir exclure totalement des artefacts expérimentaux, bien que le ralentissement ait persisté à travers les analyses de sensibilité.
Les résultats ne concluent pas que « l’IA n’apporte aucun gain de vitesse aux développeurs ». Ils indiquent plutôt que, pour des experts sur des bases de code profondément connues et avec des standards de qualité élevés, l’IA du début 2025 a introduit des retards. L’article lui-même note que les résultats concordent avec des gains potentiellement substantiels sur du développement greenfield ou du code non familier — l’annexe documente des développeurs trouvant l’IA la plus bénéfique précisément sur des tâches nouvelles : « première fois avec des Git hooks, l’IA m’a fait gagner 3 heures ».
Tout, dans la façon dont les développeurs apprennent, a été construit autour du savoir-faire : mémoriser la syntaxe, apprendre les patterns, s’entraîner jusqu’à pouvoir produire du code fonctionnel à partir d’une page blanche. Les entretiens d’embauche le testent. Les cours l’enseignent. Les carrières étaient classées selon ce critère.
Puis les LLM ont rendu la production quasiment gratuite. Décrivez ce que vous voulez, et du code qui a l’air de fonctionner apparaît en quelques secondes. Selon les propres chiffres de Google, plus d’un quart de son nouveau code est désormais généré par l’IA. La page blanche n’est plus l’ennemi.
Il est tentant d’en conclure que le métier est simplement devenu plus facile. La vraie question a changé sous nos pieds : si n’importe qui peut générer une réponse, qu’est-ce qui distingue un bon développeur d’un mauvais ?
La compétence rare n’est plus de produire la réponse. C’est de voir, rapidement et de façon fiable, si une réponse est bonne, et de savoir comment critiquer le modèle pour en obtenir une meilleure. Appelons cela le savoir-voir. Le savoir-faire livre le premier jet. Le savoir-voir décide si ce jet a sa place en production.
Parce que la production a été coûteuse pendant cinquante ans, nos réflexes assimilent taper du code à travailler, et produire à progresser. La relecture était l’activité de bas statut, la chose qu’on faisait sur le code des autres, rapidement, avant de retourner au « vrai travail ». Personne n’a construit une carrière en étant excellent pour lire du code. Cette habitude est aujourd’hui exactement à l’envers.
Générer est bon marché. Vérifier est le nouveau centre de coût. L’essai randomisé contrôlé de METR a suivi des développeurs open source expérimentés sur leurs propres bases de code matures, et a mis au jour un résultat gênant : avec des outils d’IA, ils ont mis 19 % de temps en plus pour terminer leurs tâches, tout en étant convaincus d’avoir été 20 % plus rapides. Où est passé le temps ? Pas dans la frappe. Les développeurs n’ont accepté que moins de 44 % des suggestions de l’IA, et une majorité a rapporté un nettoyage important sur le code qu’ils ont accepté. Lire, juger et corriger — le travail de savoir-voir — a discrètement absorbé les gains.
Votre sentiment de productivité n’est pas une mesure. Cette même étude a révélé un écart d’environ 40 points entre vitesse perçue et vitesse réelle. Le rapport DORA de Google, s’appuyant sur 39 000 professionnels, a trouvé le même schéma à grande échelle : alors que l’adoption de l’IA augmentait de 25 %, la vitesse de livraison baissait et la stabilité du système chutait de 7,2 %, tandis que trois quarts des développeurs se sentaient plus productifs. Le savoir-voir commence par se méfier du ressenti. Il faut instrumenter la réalité : temps de réalisation des tâches, taux de défauts, profondeur des relectures. Si vous ne pouvez pas voir clairement votre propre performance, vous ne pouvez certainement pas voir celle du modèle.
La meilleure production revient aux meilleurs critiques. Un LLM est comme un collègue junior infiniment rapide et d’une confiance illimitée : le premier jet arrive en quelques secondes, l’air soigné, occasionnellement faux de manières conçues pour passer inaperçues. Ce qui améliore le jet suivant, ce n’est pas un vague « améliore ça », c’est une critique précise. Nommez le défaut : « ceci ignore le cas limite du fuseau horaire », « ceci duplique la logique de nouvelle tentative du client », « ce test n’affirme rien ». Les développeurs qui obtiennent des résultats remarquables font tourner une boucle serrée : définir à quoi ressemble le « bon » avant de prompter, relire le résultat comme un relecteur senior hostile face au code d’un junior, et renvoyer des défauts précis et nommés. Être le critique principal n’est pas une surcharge du flux de travail avec l’IA. C’est le flux de travail.
Deux objections légitimes. « D’autres études montrent de vrais gains. » Vrai — une grande étude menée chez Microsoft et Accenture a constaté que les développeurs utilisant Copilot achevaient 26 % de tâches en plus. Les deux résultats peuvent coexister : les gains se concentrent là où les tâches sont autonomes et la vérification bon marché ; les pertes se concentrent dans les systèmes complexes et interconnectés, où repérer une faille subtile est difficile. La variable qui sépare les deux études est précisément le coût du jugement. « Les modèles deviendront assez bons pour que la vérification n’ait plus d’importance. » Plus les modèles s’améliorent, plus leurs erreurs passent d’évidentes à plausibles — fausses d’une manière qui semble juste. L’amélioration relève la barre pour le critique ; elle ne le met pas à la retraite.
Lisez plus de code que vous n’en écrivez. Relire, de façon hostile, ligne par ligne, en se demandant « qu’est-ce qui casserait ça ? », est désormais la pratique centrale, pas la corvée.
Écrivez la définition du « terminé » avant de prompter. Si vous ne pouvez pas énoncer à quoi ressemble le bon résultat, vous accepterez tout ce qui a l’air fini.
Construisez un vocabulaire de critique. Les modèles répondent à la précision. « C’est faux » produit un remaniement aléatoire ; « ceci laisse fuir la connexion sur le chemin d’erreur » produit une correction.
L’IA n’a pas rendu les développeurs remplaçables. Elle a fait de leur jugement le produit tout entier.
