Votre vélocité de dev a triplé. Votre coût total, personne ne sait s'il monte ou descend.

Un week-end. C'est le temps qu'il a fallu à une équipe pour livrer un prototype qui a arraché des applaudissements en comité de direction. Trois écrans, une intégration, une démo fluide — et une facture de tokens dérisoire au regard du temps économisé. Six mois plus tard, la même fonctionnalité mobilise deux ingénieurs à plein temps : il faut comprendre un code que personne n'a structuré, retrouver les hypothèses que personne n'a écrites, colmater une faille qu'un audit a remontée en production. Le prototype était gratuit. Le système, lui, coûte une fortune.

Cette histoire, beaucoup de directions techniques la vivent en 2026 sans la nommer. Leurs tableaux de bord disent que la vélocité de production a bondi, que l'implémentation est passée de semaines à heures — mais la question qui compte reste sans réponse. L'organisation s'enrichit-elle, ou s'appauvrit-elle, à chaque feature livrée ? Le compteur de vélocité monte. Le compteur de valeur, personne ne le regarde — parce que personne ne sait où il est.

C'est le point aveugle de l'ère agentique. Et c'est un point aveugle comptable, pas technique. Tant qu'on mesure l'IA en ingénierie à l'aune de la vitesse de production, on optimise le mauvais chiffre. Le whitepaper de Google The New SDLC With Vibe Coding (Osmani, Saboo, Kartakis, mai 2026) le pose sans détour : pour un décideur, l'indicateur critique n'est pas la vélocité du développeur. C'est le coût total de possession (Industrie · Google). Et le TCO, à l'ère IA, obéit à une économie d'investissement que la plupart des organisations n'ont pas encore mise au bilan.

Le bon indicateur n'est pas la vélocité, c'est le coût total de possession

Tout DAF connaît la distinction. Le CapEx, c'est la dépense d'investissement : l'argent qu'on engage une fois pour construire un actif qui servira longtemps. L'OpEx, c'est la dépense de fonctionnement : le coût récurrent pour faire tourner, corriger, maintenir cet actif au quotidien. Une usine se construit en CapEx ; elle se fait tourner en OpEx. La gestion saine d'une entreprise consiste, en grande partie, à arbitrer entre les deux : combien investir d'avance pour réduire le coût de fonctionnement ensuite.

Le whitepaper de Google applique cette grille au développement logiciel à l'ère des agents, et c'est là que tout devient clair. Le CapEx, c'est l'investissement initial pour construire le système qui produira le logiciel : les spécifications, les schémas d'API, les suites de tests, le contexte structuré que les agents consommeront. L'OpEx, c'est le coût continu pour faire tourner ce système, corriger ses erreurs et le maintenir. Et le whitepaper ajoute la précision qui change la donne : à l'ère IA, cet OpEx est largement dicté par l'économie du token (Industrie · Google).

Cette phrase mérite qu'on s'y arrête, car elle déplace le débat. Tant que produire du code coûtait des heures-homme, l'OpEx logiciel était une affaire de masse salariale, lente à bouger, prévisible. Désormais, une part croissante de ce coût se règle en tokens — l'unité que les modèles de langage facturent à chaque appel. Comme le résume WeNvision dans son analyse de la tokenomics : « le token est la nouvelle unité de mesure des dépenses technologiques », et « les coûts et l'efficacité des tokens sont devenus une préoccupation au niveau des PDG, pas une note de bas de page technique » (Storment, repris) (WeNvision). Le one-pager SDLC AI de SFEIR le formule autrement, et c'est l'angle qui compte pour qui pilote un budget : le token est un intrant, pas un résultat. On n'achète pas des tokens ; on achète des features livrées, maintenues, sûres. Le token est le carburant ; le TCO mesure ce qu'on parcourt avec.

À partir de là, la question stratégique se reformule proprement. Face à une feature à livrer, une organisation a le choix entre deux modèles d'investissement radicalement différents. L'un minimise le CapEx et explose l'OpEx. L'autre fait l'inverse. Et le piège, c'est que le premier paraît toujours le moins cher — au début.

Modèle A : la dette cachée du vibe coding

Le premier modèle, le whitepaper de Google le nomme par son terme désormais consacré : le vibe coding. L'expression vient d'Andrej Karpathy (février 2025), qui décrivait l'idée de « s'abandonner complètement aux vibes » — prompter une IA, accepter le résultat, passer à la suite, avec une vérification minimale (Industrie · Google). Pour un prototype, un script jetable, une démo, c'est imbattable : on obtient un output fonctionnel en un temps record, sans écrire de spécification, sans construire de harnais, sans suite de tests. Le CapEx est proche de zéro. C'est tout son attrait, et c'est réel.

Mais ce CapEx qu'on n'a pas dépensé ne disparaît pas. Il est reporté en OpEx récurrent — et c'est là que se loge la dette cachée. Le whitepaper en décompose trois postes, et chacun parle directement à un directeur financier.

Le premier est le token burn rate, le taux de combustion de tokens. Sans contexte structuré ni garde-fous, l'agent réussit rarement du premier coup. On entre alors dans une boucle de prompting : reformuler, relancer, corriger, relancer encore. Chaque itération brûle des tokens, et le faible taux de réussite au premier essai transforme une dépense ponctuelle en hémorragie continue (Industrie · Google). Le deuxième poste est la maintenance tax, la taxe de maintenance. Le code produit en vibe coding est non structuré, du « spaghetti » que personne n'a pensé pour durer ; six mois plus tard, le faire évoluer demande des jours de rétro-ingénierie pour reconstituer une logique que personne n'avait documentée (Industrie · Google). C'est exactement le scénario du prototype du week-end : la gratuité initiale était un emprunt, et l'intérêt se paie en jours-ingénieur. Le troisième poste est la security remediation : corriger une faille découverte en production coûte exponentiellement plus cher que de l'avoir prévenue en phase de design (Industrie · Google). Toute la discipline du shift-left sécurité tient dans cette courbe — et le vibe coding la prend à rebours.

Mis bout à bout, ces trois postes dessinent un profil financier précis : Low CapEx, High OpEx. Un coût d'entrée dérisoire, suivi d'un coût de possession qui s'alourdit à mesure que le système vit. WeNvision résume crûment le risque pour qui industrialise sans structure : « une SDLC dopée à l'IA se contentera […] d'amplifier les problèmes et de vous aider juste à aller plus vite… dans le mur » (WeNvision). Le vibe coding n'est pas une mauvaise pratique en soi — c'est un excellent outil de prototypage. Le problème commence quand on traite un mode d'exploration jetable comme un mode de production. Sur la frontière entre les deux, et sur ce qui les distingue techniquement, nous renvoyons à notre comparatif dédié, vibe coding contre agentic coding ; ici, ce qui nous intéresse n'est pas la définition, c'est la facture.

Modèle B : l'investissement agentic, un CapEx amortissable

Le second modèle inverse l'arbitrage. L'agentic engineering — le bout discipliné du spectre, où l'IA implémente sous spécifications, tests et boucles de feedback conçus par l'humain — consiste à investir d'avance dans le système. C'est un profil High CapEx, Low OpEx (Industrie · Google).

Concrètement, en quoi consiste ce CapEx ? En trois choses, que le whitepaper énumère. D'abord, les schémas d'API : les contrats explicites qui disent ce que chaque composant attend et produit. Ensuite, les suites de tests déterministes : des tests qui, pour une entrée donnée, vérifient une sortie attendue — le filet qui rend toute modification ultérieure sûre. Et surtout, troisième pilier et le plus sous-estimé, structurer le contexte de l'agent : lui fournir un environnement de travail dense et fiable plutôt que de le laisser deviner (Industrie · Google). Cet investissement n'est pas une dépense perdue. C'est la construction d'un actif — au sens le plus comptable du terme.

Le whitepaper donne à cet actif un nom qui dit tout : le modèle de l'usine. « La production première du développeur n'est plus le code — c'est le système qui produit le code » (Industrie · Google). On ne paie plus pour assembler chaque pièce à la main ; on construit la chaîne de production et les contrôles qualité, puis on la fait tourner. C'est précisément la thèse que SFEIR place au centre de son cycle de développement augmenté — le code est le sous-produit, l'actif réel est la connaissance que le système accumule — détaillée dans notre article pilier sur le SDLC piloté par l'IA.

Et voici la conséquence comptable, la seule qui compte ici : une fois ce système construit, le coût marginal d'expédier et de maintenir une feature chute (Industrie · Google). Le CapEx élevé du départ s'amortit sur chaque feature suivante. La première coûte cher — il a fallu bâtir les specs, les tests, le contexte. La dixième coûte une fraction de la première, parce qu'elle réutilise l'actif déjà payé. C'est la définition même d'un investissement amortissable : une dépense initiale qui se répartit, et se rentabilise, sur la durée de vie de l'actif.

Cet amortissement n'est pas une vue de l'esprit ; il se mesure. SFEIR observe, sur ses propres cycles, − 30 % d'itérations de correction après dix cycles — la preuve, mesurable, que la capitalisation paie (Mesuré · SFEIR). Ce chiffre ne vient pas d'un modèle plus intelligent : il vient du fait que les leçons d'un cycle — un bug récurrent, une revue qui bute toujours au même endroit — sont consignées en règles automatiques rechargées au cycle suivant. La courbe de coût ne descend pas par magie ; elle descend parce que le système se souvient, et que ce qu'il a appris ne se repaie pas. Sur le mécanisme de cet amortissement et le ROI composé qu'il produit, voir notre article sur la capitalisation et le compound engineering.

Le point de croisement : 3 à 10× plus cher par feature

À ce stade, un décideur lucide objectera : les deux modèles ont chacun leur domaine. Et c'est juste. L'avantage du vibe coding est réel — la vitesse au premier output. L'avantage de l'agentic engineering est d'un autre ordre — le passage à l'échelle soutenable (Industrie · Google). La vraie question n'est donc pas « lequel est meilleur dans l'absolu », mais « à partir de quand le second devient-il moins cher que le premier ».

Le whitepaper de Google répond par un graphique, sa Figure 9, et par un chiffre qui devrait figurer dans toute analyse d'investissement IA. Passé un certain volume — le point de croisement — le vibe coding coûte 3 à 10 fois plus cher par feature que l'agentic engineering (Industrie · Google). En deçà de ce point, pour un POC ou un projet jetable, le vibe coding gagne, parce que le CapEx agentic ne s'est pas amorti. Au-delà, pour tout système destiné à vivre et à grandir, l'écart s'inverse brutalement et ne fait que se creuser : le coût récurrent du vibe coding s'accumule pendant que le coût marginal agentic s'effondre.

C'est exactement le sort du prototype du week-end : tant qu'il restait une démo, il était imbattable ; le jour où il est entré en production, il a basculé du bon côté de la courbe pour le mauvais. Le whitepaper condense cette économie en une maxime qui tient lieu de doctrine : « Structure scales, vibes don't » — la structure passe à l'échelle, les vibes non (Industrie · Google). La Tokenomics Foundation, projet de la Linux Foundation lancé avec la FinOps Foundation, dit la même chose dans le langage du coût : « l'efficience est un choix de conception ; le coût de l'IA est façonné par l'architecture, pas seulement par l'usage » (Tokenomics Foundation).

Pour un décideur, la conclusion est nette. Choisir le vibe coding pour un système de production, ce n'est pas faire une économie. C'est contracter un emprunt à taux variable, dont le taux grimpe avec le succès du produit. Plus la feature marche, plus elle est sollicitée, plus elle doit évoluer — et plus la dette cachée se rappelle au bilan.

Context engineering : le levier financier, pas seulement une compétence technique

Si le CapEx agentic se résume à un pilier, c'est celui-ci : structurer le contexte. Et c'est aussi celui qu'on présente le plus souvent comme une affaire purement technique, réservée aux ingénieurs. C'est une erreur de cadrage. Le whitepaper de Google est explicite : le context engineering est un levier financier (Industrie · Google).

La mécanique est d'une simplicité comptable. Les modèles de langage facturent au token. Or la tentation naturelle, quand un agent manque de contexte, est de tout lui donner : injecter l'intégralité du dépôt de code dans chaque prompt. Le whitepaper tranche : injecter un repo de 100 000 tokens dans chaque prompt est non viable à l'échelle (Industrie · Google). Non seulement c'est ruineux à chaque appel, mais c'est contre-productif — un agent noyé sous le contexte performe moins bien qu'un agent bien briefé. L'art consiste à fournir un payload dense, à fort signal : un fichier d'instructions structuré — ce que les outils nomment AGENTS.md, CLAUDE.md ou GEMINI.md — assorti de garde-fous explicites. Ce payload bien conçu augmente le taux de réussite au premier coup et évite les coûteuses boucles d'essai-erreur (Industrie · Google). Autrement dit, il attaque directement le premier poste d'OpEx du modèle A : le token burn rate.

Le whitepaper affine en distinguant le contexte statique — toujours chargé, donc coûteux à chaque appel — du contexte dynamique, chargé à la demande, donc bien plus efficient (Industrie · Google). SFEIR a fait de cette discipline un cadre nommé, le Context Engineering — « l'art de nourrir les agents IA » — et en souligne la nature économique : là où le prompt engineering donne un ROI linéaire (chaque interaction repart de zéro), le context engineering donne un ROI composé, parce que le contexte structuré se réutilise et s'enrichit d'une session à l'autre. C'est la traduction technique exacte de l'amortissement comptable du CapEx.

Le message pour un décideur tient en une phrase de WeNvision : « l'enjeu du FinOps n'est pas tant de réduire les coûts que d'optimiser l'efficience » (WeNvision). On ne pilote pas cette économie en coupant les budgets de tokens ; on la pilote en investissant dans le contexte qui rend chaque token plus productif. Le context engineering n'est pas une ligne de coût — c'est le levier qui actionne toutes les autres.

Intelligent model routing : router l'intelligence comme on route le capital

Il reste un dernier levier, et c'est peut-être le plus directement actionnable au niveau d'un budget. Le whitepaper l'appelle l'intelligent model routing, le routage intelligent des modèles. L'idée : tous les modèles ne coûtent pas la même chose, et toutes les tâches ne demandent pas la même intelligence. Faire tourner chaque tâche sur le modèle le plus puissant — donc le plus cher — est un gaspillage aussi flagrant que de payer un architecte senior pour relire chaque ligne de code.

La règle de routage proposée par le whitepaper est simple. Les gros modèles — coûteux, puissants — pour le complexe : les exigences, l'architecture, l'implémentation initiale, là où le jugement et la profondeur comptent. Les modèles plus petits et moins chers pour le déterministe : la génération de tests, la revue de code, le monitoring CI/CD, toutes ces tâches cadrées où une réponse correcte se vérifie mécaniquement (Industrie · Google). Le résultat, dit le whitepaper, est que ce routage effondre le coût opérationnel en tokens — il attaque l'OpEx à sa racine (Industrie · Google).

Ce principe n'est pas propre à Google. La Tokenomics Foundation le pose en aphorisme : « plus gros n'est pas toujours mieux ; le meilleur système d'IA n'est pas toujours celui qui utilise le modèle le plus cher » (Tokenomics Foundation). Et la FinOps Foundation en fait une métrique opérable, le LLM Model Choice Quality Score Alignment, qui compare le niveau de capacité requis par une tâche à celui du modèle qu'on lui affecte, pour détecter le sur-dimensionnement (FinOps Foundation). Le sur-dimensionnement de modèle est, à l'ère IA, l'équivalent du serveur surprovisionné de l'ère cloud : un coût pur, invisible tant qu'on ne le mesure pas, évitable dès qu'on le route. C'est une intuition financière familière : on alloue le capital cher là où il crée le plus de valeur, et le capital bon marché partout ailleurs. Router les modèles, c'est router l'intelligence comme on route le capital — au plus juste de ce que chaque tâche exige.

Ce que ça change pour un décideur : traiter l'IA comme un investissement d'ingénierie

La question n'a jamais été « quel assistant déployer » ni « comment aller plus vite » : c'était comment investir. Le whitepaper de Google formule, à destination explicite des organisations, trois recommandations qui sont autant de décisions d'investissement (Industrie · Google). La première : traiter le développement assisté par l'IA comme un investissement d'ingénierie, pas comme une fonctionnalité de productivité. Une feature de productivité, on l'achète et on la consomme. Un investissement d'ingénierie, on le porte au bilan, on l'amortit, on en attend un retour. Toute la différence entre le modèle A et le modèle B tient dans ce basculement de regard. La deuxième : investir dans le substrat de production avant de scaler. On ne met pas à l'échelle un système dont le CapEx n'a pas été payé — on ne fait qu'amplifier sa dette cachée. La troisième : traiter les composants du harnais comme un actif d'équipe partagé. Un schéma d'API, une suite de tests, un fichier de contexte bien conçu ne servent pas un projet, ils servent tous les projets qui les réutilisent — l'amortissement joue alors à l'échelle de l'organisation entière, pas d'une seule équipe.

C'est précisément la posture que SFEIR a choisie en se l'appliquant d'abord à elle-même, avec un objectif assumé de 850 consultants 100 % augmentés par l'IA fin 2026 avant tout déploiement client. Et c'est ce qui donne son sens au seul ordre de grandeur budgétaire que SFEIR met en avant : un poste augmenté à ~ 10 €/h (Mesuré · SFEIR). Ce chiffre n'est pas un prix catalogue, et surtout il n'est jamais à comparer à zéro — il se compare au coût horaire chargé d'un ingénieur, et c'est dans cet écart que se lit le retour sur le CapEx investi. De même que les − 30 % d'itérations après dix cycles ne sont pas un effet d'annonce : c'est l'amortissement du CapEx, observé sur la durée (Mesuré · SFEIR).

Un dernier mot de rigueur, parce que la discipline sur les chiffres fait partie de la thèse. Capturer la sortie réelle de chaque étape plutôt que la déclaration de l'agent — la discipline de preuve — est un principe de fonctionnement, jamais un pourcentage de performance. C'est cette rigueur qui distingue un investissement piloté d'un pari.

Reste alors la seule question qui vaille, celle du tableau de bord du début. La vélocité de vos équipes a peut-être triplé ; c'est une bonne nouvelle, mais ce n'est pas la mesure. La mesure, c'est de savoir si chaque feature livrée enrichit ou appauvrit votre bilan — si vous construisez un actif qui s'amortit, ou si vous accumulez une dette qui se rappellera à vous dans six mois. Le pilotage opérationnel de cette économie — le coût par outcome, les cadrans de suivi — fait l'objet de notre article sur la maîtrise des coûts agentiques. Mais la décision, elle, se prend en amont, et elle est comptable avant d'être technique : investir d'avance dans le système, ou payer indéfiniment pour l'avoir évité. La structure passe à l'échelle. Les vibes, non.

Sources

1. Addy Osmani, Shubham Saboo, Sokratis Kartakis (Google), The New SDLC With Vibe Coding — From ad-hoc prompting to Agentic Engineering — kaggle.com, mai 2026.
2. Olivier Rafal (WeNvision), Tokenomics foundation : l'ère du FinOps appliqué à l'IA est officiellement ouverte — wenvision.com, juin 2026.
3. SFEIR — SDLC AI : ce qu'on a mesuré (one-pager), matière first-party, juin 2026.
4. Tokenomics Foundation (Linux Foundation & FinOps Foundation), About — Tokenomics Foundation — tokeneconomics.com, juin 2026.
5. FinOps Foundation, FinOps for AI Overview — finops.org, février 2026.