Remplacer des développeurs par de l'IA coûte plus que cela n'économise
Il existe une phrase qui circule parmi les fondateurs soutenus par du capital risque avec une fréquence qui devrait inquiéter n'importe quel directeur financier : "Je peux remplacer tout le monde par de l'IA." La dernière version de cet argument provient d'une startup qui a récemment annoncé publiquement sa décision de remplacer son équipe de développement par un outil de génération de code, baptisé OpenClaw. Cet annonce a été accueillie par un mélange d'applaudissements dans certains forums technologiques, et d'alarme dans d'autres. Ni les applaudissements ni l'alarme ne capturent vraiment ce qui se passe dans le compte de résultats de cette entreprise.
Ce que cette histoire décrit n'est pas une histoire d'efficacité. C'est une histoire sur la manière dont nous mesurons — et comment nous distordons — le coût de production de logiciels.
L'erreur de confondre prix et coût
Quand une entreprise licencie ses développeurs et engage une solution d'IA pour les remplacer, ce qu'elle observe dans son relevé bancaire le mois suivant semble être une victoire : la masse salariale diminue, les dépenses en licences logiciels ne représentent qu'une fraction des salaires précédents, et la marge opérationnelle s'améliore sur le papier. C'est la photographie à court terme. La réalité à long terme est tout autre.
Le coût d'un développeur senior ne se limite pas à son salaire. C'est le savoir accumulé sur l'architecture du produit, les décisions prises il y a dix-huit mois et leurs raisons, la confiance des clients qui appellent directement ce développeur, et la capacité à détecter qu'une fonctionnalité techniquement correcte peut être stratégiquement risquée. Ce savoir ne réside pas dans un dépôt GitHub. Il existe dans des conversations, dans des jugements, dans la mémoire organisationnelle.
Lorsque cet actif sort par la porte, le coût ne disparaît pas : il se transforme. Il se traduit en temps d'adaptation chaque fois que l'outil d'IA produit un code que personne dans l'entreprise ne peut auditer de manière fiable, en dette technique qui s'accumule silencieusement, et en coûts de consultants externes lorsque le système échoue en production à deux heures du matin. Aucun de ces coûts n'apparaît dans la ligne des "salaires" du compte de résultats, ce qui les rend politiquement confortables et économiquement dangereux.
Une startup sans développeurs humains capables de vérifier la production de l'IA n'a pas réduit sa dépendance technologique : elle l'a concentrée sur un fournisseur externe unique sur lequel elle n'a aucune influence structurelle. Cela ne représente pas une efficacité opérationnelle ; c'est une fragilité déguisée en marge.
La logique du fournisseur unique et ses conséquences distributives
Il existe un modèle bien documenté en stratégie commerciale qui décrit ce qui se produit lorsqu'une entreprise accorde le pouvoir de négociation à un unique fournisseur sans alternative viable. Le fournisseur, de manière rationnelle, ajuste ses prix à la hausse dès qu'il détecte que le coût de changement pour le client est suffisamment élevé.
Dans ce cas, la startup ne se contente pas de conférer ce pouvoir à OpenClaw — ou à toute plateforme d'IA qu'elle choisit — mais elle est en train de détruire activement sa capacité à négocier à l'avenir. Sans une équipe technique interne capable d'évaluer les alternatives, de migrer vers un autre outil ou de construire des compétences en interne, l'entreprise se retrouve piégée. Le fournisseur d'IA le sait. Les investisseurs de ce fournisseur le savent. Et les termes contractuels refléteront cette connaissance plus tôt que la startup ne l'anticipera.
Cela n'est pas une projection spéculative. C'est la mécanique standard de tout marché où un acheteur élimine ses options de substitution. Le prix qu'il paie aujourd'hui pour la licence d'IA n'est pas le prix qu'il paiera dans trois ans. Et d'ici là, il ne disposera plus du talent interne pour construire une sortie.
L'argument que l'IA "démocratise" le développement de logiciels a du mérite dans certains contextes : petites équipes nécessitant une prototypage rapide, fondateurs techniques souhaitant réduire les frictions dans les tâches répétitives, ou entreprises utilisant l'IA comme couche d'accélération sur une équipe humaine qui continue à prendre des décisions. Mais il y a une différence structurelle entre utiliser l'IA pour que vos développeurs produisent plus, et utiliser l'IA pour ne pas avoir de développeurs. La première stratégie multiplie la capacité. La seconde élimine le jugement.
Quand le modèle économique dépend du fait que personne ne fasse les comptes
Il y a une question qui n'apparaît pas dans le communiqué de cette startup mais que tout investisseur devrait poser avant d'applaudir : qui valide la production ? Le code généré par l'IA n'est pas intrinsèquement mauvais. Mais le code généré par l'IA sans révision humaine dans un contexte commercial est une pari connu qui se transforme en dette technique, en vulnérabilités de sécurité non détectées, et en produits qui fonctionnent en démonstration mais échouent sous une charge réelle.
La narrative de "je peux remplacer tout le monde par de l'IA" a un public très spécifique : les investisseurs qui souhaitent voir le taux de burn descendre. Elle n'est pas conçue pour les clients, qui ont besoin de logiciels fiables. Elle n'est pas conçue pour les développeurs licenciés, qui perdent leurs revenus. Et, à moyen terme, elle n'est pas non plus conçue pour le fondateur qui héritera d'une architecture technique que personne dans son entreprise ne comprend complètement.
Ce que cette décision optimise, ce n'est pas la création de valeur du produit ; c'est l'optimisation de la métrique qui rend l'image plus attrayante pour le prochain tour de financement. Il s'agit d'une distinction que les directeurs financiers des entreprises qui acquerront éventuellement cette startup — si elle atteint ce stade — devront évaluer avec précision chirurgicale.
Le schéma n'est pas nouveau. L'économie des plateformes montre depuis une décennie comment les entreprises qui exploitent leurs fournisseurs pour améliorer leurs marges à court terme finissent par avoir des chaînes d'approvisionnement qui s'effondrent au moment le moins opportun. Le développeur de logiciels est, dans ce modèle, le fournisseur dont on se débarrasse. La différence avec un fournisseur de matières premières est que ce fournisseur était aussi le gardien du savoir technique du produit. Le supprimer a un coût qui n'apparaît sur aucune facture jusqu'à ce qu'il ressorte sur toutes.
Le capital qui n'apparaît sur aucun bilan
Il existe des actifs que les systèmes comptables modernes sont encore incapables de capturer avec précision : les connaissances tacites d'une équipe, la confiance accumulée avec des clients techniques exigeants, et la capacité organisationnelle d'apprendre des erreurs de son propre système. Une startup qui remplace son équipe de développement par de l'IA ne liquide pas une ligne de coût ; elle liquider ces actifs sans inscrire la charge correspondante.
Le marché finit par effectuer cette comptabilité. Il le fait lorsque le produit ne peut pas s'adapter à un changement réglementaire parce que personne ne sait précisément comment il a été construit. Il le fait lorsqu'un client d'entreprise effectue son audit technique avant de signer et découvre qu'il n'y a pas d'équipe humaine responsable de l'architecture. Et il le fait lorsque le prochain fondateur souhaitant acquérir ou fusionner avec cette entreprise réduit agressivement la valorisation parce que l'actif technique central n'a pas de propriétaire humain identifiable.
La startup qui a remplacé ses développeurs par OpenClaw ne réduit pas la friction au moment de l'échelle. Elle transfère la valeur que ses développeurs généraient — vers ses clients, vers son produit, vers sa capacité à s'adapter — à un fournisseur externe qui n'a aucun intérêt aligné avec sa survie. Les développeurs ont perdu leurs revenus. Les clients ont perdu leurs interlocuteurs techniques. Le fournisseur d'IA a gagné un client dépendant. Cette distribution, mesurée froidement, ne décrit pas l'efficacité : elle décrit l'extraction. Et les modèles fondés sur l'extraction ne sont durables que tant que l'argent qui les subventionne dure.
