Par Adrien Blandin
Ex-CTO lePERMISLIBRE (3 → 30 personnes, IPO). Depuis 2024, j'audite la tech et l'organisation de startups 10-80 personnes. Voir le parcours.
Le débat sur l'IA ressemble de plus en plus au reste du débat public : deux camps, pas de milieu. D'un côté ceux qui la refusent, convaincus que rien ne changera vraiment, persuadés qu'ils pourront continuer dans cinq ans comme ils le font aujourd'hui. De l'autre ceux qui ont le changement au fond des tripes, persuadés qu'il suffit de dire aux gens "utilisez l'IA" pour que leur entreprise fasse x10 en productivité. Ceux-là mêmes qui mesurent désormais la performance au nombre de tokens dépensés. Jensen Huang, le patron de Nvidia, l'a dit sans détour lors du GTC 2026 : il serait "profondément alarmé" si un ingénieur payé 500 000$ par an ne consommait pas au moins 250 000$ de tokens annuellement. Il propose même d'ajouter un budget tokens équivalent à la moitié du salaire de base, par-dessus le salaire lui-même. La consommation de tokens comme indicateur de productivité.
Entre les deux, le vide.
Quand j'essaie d'être mesuré, de dire que oui, c'est une révolution, et que non, ce n'est pas si simple à industrialiser, je passe pour quelqu'un qui n'a rien compris. Qui veut retourner à l'âge de pierre. Pourtant j'utilise l'IA tous les jours. Je lance des migrations d'infrastructure complètes, des réécritures de projets massifs. Les gains sont réels.
Mais j'ai managé des équipes de 30 personnes. Et je sais qu'on ne change pas la façon de travailler de 30 personnes en leur disant "utilisez ça".
J'ai discuté récemment avec deux personnes qui travaillent dans la tech. L'un développe des workflows agentiques depuis un an, convaincu, enthousiaste, presque révolté que tout le monde n'ait pas encore basculé. "C'est une révolution, les réticences n'ont plus de sens." L'autre dirige une équipe de 50 personnes. Il a créé une cellule R&D dédiée à l'IA, en isolation, avant d'envisager de généraliser à l'ensemble de ses équipes.
Même table. Deux postures radicalement différentes.
Le premier n'a pas tort sur le fond : c'est une révolution. Le second ne manque pas d'ambition : il construit les conditions avant de généraliser. Et c'est précisément là que le débat achoppe. Parce que dans l'état actuel des choses, construire les conditions n'est pas de la prudence excessive. C'est de l'ingénierie.
Peter Steinberger, le fondateur d'OpenClaw, a publié sa facture mensuelle d'utilisation d'OpenAI : 1,3M€ en 30 jours. 603 milliards de tokens, 7,6 millions de requêtes, environ 100 agents Codex en parallèle pour une équipe de 3 personnes.
La facture est couverte par OpenAI, son employeur. C'est de la R&D, pas une décision business ordinaire. Steinberger le dit lui-même : il cherche à répondre à une question de recherche. "Comment builderait-on si les tokens ne coûtaient rien ?"
C'est une question légitime. Mais derrière l'extase, derrière le buzz et la com, elle en cache une autre, sans réponse : est-ce que ces 1,3M€ ont produit de la valeur ? Pour donner un ordre de grandeur, 1,3M€ par mois représente le coût mensuel d'environ 200 développeurs français confirmés, charges comprises. Ce n'est pas une comparaison fonctionnelle, les agents et les développeurs ne font pas le même travail. C'est une mise en perspective budgétaire. Est-ce qu'OpenClaw est plus rapide, plus stable, plus maintenable aujourd'hui qu'il y a un mois ?
Nous n'en savons rien. Il n'y a pas de réponse publique à cette question. Et ce silence n'est pas un reproche adressé à Steinberger. C'est un constat structurel : nous n'avons pas encore les outils pour mesurer ça. Pas les métriques, pas les benchmarks, pas les standards d'évaluation qui permettraient de répondre honnêtement à cette question.
Ce n'est pas parce que nous pouvons produire vite qu'il faut nécessairement le faire. Derrière les tokens dépensés, il y a de la puissance de calcul, de l'énergie souvent fossile, des matériaux rares, et toujours de l'argent. Quel est l'intérêt de produire plus vite, plus de choses qui ne servent à rien ? Dépenser sans cadre et gaspiller des ressources précieuses n'a jamais posé les fondations d'une entreprise stable.
Le vrai enjeu de notre métier a toujours été de trouver ce qui valait la peine d'être construit. L'IA ne résout pas cette question. Elle l'amplifie.
On pense à tort que le frein à la vélocité d'une équipe, c'est le nombre de développeurs. C'est faux.
C'est l'argent.
Avec plus d'argent, vous avez plus d'équipes, plus de projets simultanés, et inévitablement plus de friction entre eux. Le nombre finit toujours par créer de la friction et une baisse de la vélocité. Remplacer des développeurs par des agents qui brûlent des tokens ne change rien à ce mécanisme. Le frein reste l'argent qui finance les tokens. Plus d'argent, plus d'agents, plus de projets, plus de problèmes de coordination entre eux, moins de vélocité.
Pour avoir de l'argent, il faut un business sain. Un business qui repose sur le fait de mettre ses efforts sur les bons sujets, de la bonne manière. Et pour mettre ses efforts sur les bons sujets, il faut être capable de mesurer ce que produit chaque investissement. Ce que nous ne savons pas encore faire avec l'IA à l'échelle d'une équipe.
J'écris de moins en moins de code moi-même. J'écris même de moins en moins de documents moi-même. Et j'arrive à faire ça pour 20$ par mois, en faisant attention à mon workflow de travail, à mes process, à mes instructions, à mon contexte. En comprenant ce qui se passe derrière, là où l'IA a de la valeur et là où elle n'en a pas. En étant conscient des forces et des faiblesses, de l'infini et des limites.
L'électricité a fait sa première démonstration publique à Paris en 1881. L'électrification complète du territoire français a pris plus de cinquante ans. À peine 20% des communes étaient raccordées au sortir de la Première Guerre mondiale. Les dernières zones rurales ont été connectées dans les années 1970.
Entre l'invention et l'adoption universelle : deux générations. Pas parce que la technologie était mauvaise, mais parce que l'infrastructure manquait, les réseaux, les standards, la réglementation, la formation, les métiers. Toutes les conditions qui permettent à n'importe qui d'utiliser une technologie sans en comprendre les entrailles.
Aujourd'hui personne ne remet en question l'électricité. Elle est tellement intégrée au quotidien qu'on ne la voit plus. Pourtant en 1890, demander à un patron d'usine d'"utiliser l'électricité" sans lui fournir les standards, la formation, l'outillage, c'était lui demander l'impossible. La technologie existait. Les conditions de son adoption industrielle, non.
L'IA suit le même mécanisme. Avec une différence fondamentale : l'infrastructure à construire n'est pas physique. Elle est software et organisationnelle, comment les équipes collaborent, comment elles partagent leurs instructions et leurs règles, comment elles s'organisent pour travailler ensemble de manière reproductible, comment elles mesurent ce que l'IA produit réellement. Ce qui prendra des années, pas des décennies. Mais cette infrastructure n'existe pas encore.
Les standards ne se construisent pas dans le vide. Ils émergent d'outils qui ont fait leurs preuves, adoptés, critiqués, améliorés par des milliers d'équipes jusqu'à devenir des évidences. Git n'est pas apparu avec ses forges, ses pull requests, ses pipelines de CI/CD. Il a fallu des années d'expérimentation pour que l'écosystème autour du versioning se stabilise. Les containers ont précédé Kubernetes d'une décennie. L'outillage se construit par empirisme, lentement, par accumulation d'usages réels.
Nous sommes exactement dans cette phase avec l'IA. Et la vitesse à laquelle les outils évoluent en est la meilleure preuve.
Il y a deux ans, l'IA dans le développement, c'était de l'autocomplétion. Puis les développeurs ont commencé à dialoguer avec des agents par copier/coller dans leur éditeur. Puis l'agent s'est intégré directement dans l'IDE, capable de modifier les fichiers eux-mêmes, le développeur acceptant ou refusant chaque changement proposé. Puis sont apparus les harness, ces environnements structurés qui donnent à l'agent le contexte dont il a besoin pour produire quelque chose d'utile à l'échelle d'un projet entier. Aujourd'hui l'IDE lui-même est en train de disparaître, absorbé par des interfaces qui placent l'agent au centre et le développeur en superviseur.
Deux ans. Cinq ruptures majeures dans la façon de travailler.
Et ce rythme crée un risque que peu de gens nomment clairement. Une entreprise qui engage aujourd'hui une transition profonde de ses équipes autour d'un outil ou d'une pratique spécifique prend le pari que ce choix sera toujours pertinent dans deux ans. Vu la vitesse à laquelle le paysage se transforme, ce n'est pas un pari anodin. Recommencer une transition organisationnelle parce que les outils ont pris une direction différente, c'est du gaspillage de temps, d'énergie et de capital humain.
La prudence de certaines entreprises n'est pas de l'immobilisme. C'est de la gestion de risque sur un terrain instable. Et on ne peut pas construire de bonnes pratiques durables sur un terrain qui n'a pas encore fini de se stabiliser. C'est précisément pour ça que les standards de l'IA collective n'existent pas encore.
Nous avons passé vingt ans à construire les standards du développement moderne. DORA, le rapport annuel de Google qui mesure la performance des équipes à travers quatre métriques clés : fréquence de déploiement, délai de mise en production, taux d'échec et temps de restauration. Team Topologies, le framework qui définit comment organiser les équipes et leurs interactions pour réduire la friction cognitive. Les chapters Spotify, le modèle d'organisation en tribus et guildes qui permet de faire circuler la connaissance entre équipes autonomes. La CI/CD, le pipeline qui industrialise les tests et les livraisons pour qu'aucune mise en production ne soit un événement risqué.
Rien de tout ça n'est parfait. L'agile lui-même, dont le manifeste a été signé en 2001, reste mal appliqué dans la majorité des entreprises qui s'en réclament. Les cérémonies sans valeur, le Scrum cargo-culte, les sprints qui ne livrent rien. Les entreprises qui ratent l'agile aujourd'hui sont précisément celles qui l'ont adopté parce que c'était hype, sans se demander si elles étaient organisées pour fonctionner comme ça. Pourtant, avec vingt ans de recul, d'échecs et de succès accumulés, nous savons aujourd'hui quand et comment l'utiliser intelligemment. Nous avons les métriques pour le mesurer, les retours d'expérience pour l'adapter, les anti-patterns pour éviter les pièges les plus courants.
Ce corpus n'existe pas encore pour l'IA collective. Et les chiffres le confirment. Une étude McKinsey de novembre 2025, conduite auprès de près de 2 000 entreprises dans 105 pays, montre que 88% des organisations déclarent utiliser l'IA régulièrement dans au moins une fonction. Mais seulement un tiers ont commencé à la déployer à l'échelle de l'entreprise. Le problème, selon McKinsey, n'est pas technologique. Il est organisationnel.
Nous savons utiliser l'IA individuellement, chaque développeur a son harness, ses règles, son workflow. Les solopreneurs et les petites structures ont été les premiers à en tirer de la valeur, précisément parce qu'ils n'ont pas de contrainte organisationnelle. Un seul cerveau, un seul flux de travail. Le problème commence dès que nous sommes plusieurs.
Et dès que nous sommes plusieurs, les questions s'accumulent. Comment collaborer quand chacun travaille avec son propre assistant ? Comment partager les règles, les instructions, les contextes ? Comment mesurer ce que l'IA produit réellement à l'échelle d'une équipe ? Comment maintenir ce qu'elle génère en volume croissant ? J'ai détaillé l'étendue de ces questions ailleurs. Ce qu'elles ont en commun : aucune n'a encore de réponse industrialisée.
Le point ici est plus simple : dire "utilisez l'IA" aujourd'hui ressemble à "soyez agiles" en 2001. Juste comme intention. Insuffisant comme méthode.
Les entreprises qui avancent sérieusement sur ce sujet ne sont pas celles qui ont décrété "on fait de l'IA". Ce sont celles qui ont compris que la technologie est prête et que le vrai chantier est ailleurs : dans la façon dont les équipes collaborent, se forment, mesurent ce qu'elles produisent. Celles qui traitent l'adoption de l'IA comme on a traité l'adoption de l'agile, pas comme une déclaration d'intention, mais comme un processus d'expérimentation, d'échec, d'ajustement.
Ce chantier commence à peine. Les bonnes pratiques se construisent maintenant, dans des équipes qui acceptent de tâtonner, de documenter leurs erreurs autant que leurs succès, de partager ce qu'elles apprennent. Dans quelques années, nous aurons suffisamment de recul pour savoir ce qui fonctionne, ce qui ne fonctionne pas, dans quels contextes et pour quelles organisations. Comme nous l'avons fait avec chaque évolution structurante de notre métier.
Mais ce travail de fond est difficile à défendre publiquement. Parce que le débat ne laisse pas de place à la nuance. Ceux qui refusent l'IA en bloc ont tort : la révolution est réelle, les gains sont documentés, le mouvement est irréversible. Ceux qui s'impatientent ont tort aussi : la technologie ne suffit pas, les outils ne sont pas stabilisés, les standards n'existent pas encore. Entre les deux, ceux qui essaient d'être lucides passent pour des réfractaires.
Nous sommes pourtant nombreux dans ce vide. Mais dans le monde d'aujourd'hui, malheureusement, ne pas prendre position pour l'un des deux camps, c'est forcément prendre position pour l'autre. Celui auquel ne se rattache pas votre interlocuteur.
PS 1 - Les questions structurantes de l'IA en équipe sont détaillées dans cet article.
PS 2 - La question du déterminisme des agents, dans celui-ci.
McKinsey :
Jensen Huang, GTC 2026 :
Peter Steinberger, OpenClaw :
Audit tech — CTO freelance
Un échange de 30 minutes suffit souvent à clarifier ce qui coince. Pas de jargon, pas d'engagement. Un point de vue externe, honnête, sur votre situation.