Quand une IA développe une fonctionnalité de plusieurs jours en quelques heures, la première émotion est la bonne : c’est spectaculaire, et c’est réel. Ce qui coûtait une semaine tient dans un après-midi. Une migration largement automatisée. Un prototype qui devient présentable avant la fin de la réunion.
Puis vient une facture qu’on n’avait pas anticipée. Pas celle de l’API — celle-là, on la voit. L’autre. Celle qui arrive six mois plus tard, quand un service change ses tarifs, qu’une dépendance casse, ou qu’un collaborateur reprend un projet que plus personne ne comprend.
L’IA baisse le coût de création. Elle ne supprime pas le coût de maintenance.
Le coût de production n’est qu’une fraction du coût
Le coût apparent d’un développement, c’est ce qu’il a fallu pour le produire. Le coût réel, lui, additionne tout ce qui vient après : la relecture, les tests, les corrections, la maintenance, les dépendances, l’hébergement, les appels à des services externes, la surveillance, la sécurité, la documentation, et un jour la reprise par quelqu’un d’autre.
Autrement dit : une fonctionnalité peut être quasi gratuite à créer et très chère à conserver. L’IA agit sur la première ligne de ce calcul — la production. Elle ne touche presque à aucune des autres.
C’est un renversement de perspective inconfortable pour un dirigeant, parce que la ligne qui baisse est la plus visible, et celles qui montent sont les plus discrètes. On célèbre le coût de fabrication qui s’effondre, on ne voit pas la surface de maintenance qui gonfle en silence.
Produire dix fois plus, c’est entretenir dix fois plus
Avant l’IA, le temps imposait une sélection naturelle. Développer coûtait cher, donc on ne développait que ce qui le méritait vraiment. Cette lenteur était pénible, mais elle jouait un rôle : elle filtrait.
Aujourd’hui, cette barrière tombe. Plus de prototypes deviennent des fonctionnalités. Plus de scripts deviennent des services permanents. Plus de solutions temporaires restent en production « parce que ça marche ». L’IA permet de produire dix fois plus — donc dix fois plus de surface à maintenir, à surveiller, à sécuriser, à documenter.
Le piège est subtil : chaque décision prise isolément est raisonnable. Ce petit script qui automatise une tâche est utile. Cette dépendance qui règle un problème est justifiée. Ce service externe qui fait gagner du temps est pertinent. C’est l’accumulation qui devient ingérable, pas les briques une à une.
Les petits coûts deviennent énormes à l’échelle
Un appel d’API à quelques centimes ne mérite pas qu’on s’y arrête. Multiplié par des milliers d’exécutions par jour, il devient une ligne budgétaire. Et ce n’est que la partie assumée : il faut y ajouter les appels inutiles, les répétitions, les mauvais choix de modèles, les workflows qui transmettent trop de contexte à chaque passage.
Chez nous, cette part-là, on la traque activement. Nous utilisons un proxy maison — RTK, pour Rust Token Killer — qui réduit de 60 à 90 % la consommation de tokens sur nos opérations de développement, et une commande, rtk gain, qui affiche les économies réelles. C’est efficace, et je le recommande. Mais je me garde d’en faire la solution : optimiser le coût des tokens, c’est optimiser une seule ligne d’une facture qui en compte beaucoup.
La bonne question n’est jamais « combien coûte ce modèle ? ». C’est : combien coûte l’ensemble du processus pour produire une unité de valeur utile ? Un modèle deux fois moins cher qui exige trois allers-retours et double la relecture n’a rien économisé. Le coût pertinent se mesure au bout de la chaîne, pas au prix affiché de la brique.
La complexité est une dette qui ne figure sur aucune facture
Une solution générée vite a tendance à multiplier les briques : authentification, stockage, automatisation, analyse, validation, notifications. Chaque choix se défend séparément. L’ensemble, lui, devient un système que personne ne tient plus dans sa tête.
La complexité ne coûte rien tant que tout va bien. Elle se paie d’un coup — quand quelque chose casse, quand un tarif change, quand il faut expliquer l’architecture à un nouveau. Et je peux donner des exemples concrets, tirés de notre propre stack, parce qu’on ne les a vus qu’en les cherchant.
Un audit a exhumé chez nous une brique de journalisation restée déclarée en dépendance alors qu’elle était morte depuis des mois — retirée en urgence après un crash sur notre environnement Lambda, jamais désinstallée. Elle ne servait plus à rien, mais elle continuait de peser : dans les installations, dans les audits, dans la charge mentale de quiconque lisait le fichier de dépendances en se demandant à quoi elle servait.
Autre exemple, plus vicieux : une de nos fonctions serverless doit dupliquer manuellement du code déjà partagé ailleurs, parce que son environnement d’exécution ne supporte pas l’import entre paquets. Deux copies du même code à maintenir en parallèle — une contrainte technique invisible qui crée une dette bien réelle. Rien de tout cela n’apparaît sur une facture. Tout cela coûte.
L’infrastructure a un coût, même quand l’API est gratuite
On raisonne comme si le seul coût d’un développement était son coût de calcul. C’est faux, et une contrainte très concrète me le rappelle chaque semaine : le disque racine de notre serveur de production est étroit — 27 Go. On refuse d’y déporter la moindre charge de build ou de CI lourde, non par principe, mais parce que la place physique manque.
C’est un rappel salutaire. Le code que l’IA génère doit tourner quelque part, et ce « quelque part » a des limites, un prix, une inertie. Nous avons d’ailleurs migré notre hébergement d’une plateforme à une autre en partie pour cette raison : le coût. La production ne se déploie pas dans le vide — elle occupe des ressources qui, elles, ne baissent pas parce qu’une IA a écrit le code plus vite.
Mesurer le coût complet — y compris celui de supprimer
Si je devais résumer la discipline en une grille, elle tiendrait en quelques questions posées à chaque développement :
- Quel est son coût de création — et son coût mensuel d’exploitation ?
- Combien de temps de maintenance faut-il anticiper ?
- De combien de services externes dépend-il ?
- Que se passe-t-il si son volume est multiplié par dix ?
- Quelle valeur mesurable produit-il réellement ?
- Et — la question qu’on oublie toujours — peut-on le supprimer facilement ?
Cette dernière est la plus révélatrice. Une bonne architecture facilite autant le retrait que l’ajout. Si retirer une fonctionnalité est un chantier, c’est qu’elle a été construite comme si elle devait rester pour toujours — ce qui est rarement vrai.
L’IA ne rend pas le développement gratuit
Elle rend l’expérimentation moins chère et la production plus rapide. C’est déjà énorme, et il ne faut pas bouder ce gain. Mais elle ne supprime ni la maintenance, ni l’infrastructure, ni les erreurs, ni les arbitrages. Elle déplace le coût — de l’avant vers l’après, du visible vers l’invisible.
L’avantage n’ira donc pas aux entreprises qui produiront le plus. Il ira à celles qui sauront identifier ce qui mérite réellement d’être conservé en production — et assumer de supprimer le reste, avant qu’il ne devienne cette facture qu’on n’avait pas vue venir.
Et chez vous — connaissez-vous le coût complet de ce que votre IA a produit, ou seulement le prix qu’il a fallu pour le créer ?