Tout le monde peut coder… mais seuls les riches peuvent être grands !

Vous vous souvenez de la scène finale de Ratatouille ? Anton Ego, le critique gastronomique le plus redouté de Paris, s’assoit devant un plat préparé par Rémy et vit une épiphanie. Pendant des années, il s’était moqué de la devise du chef Auguste Gusteau : « Tout le monde peut cuisiner. » Il y voyait une insulte à la noblesse de l’art culinaire. Et pourtant, face à ce plat préparé par un rat, il comprend enfin le vrai sens de ces mots : « Tout le monde ne peut pas devenir un grand artiste. Mais un grand artiste peut surgir n’importe où. »

En lisant des articles qui célébraient encore un nouveau modèle « révolutionnaire », je pensais exactement à cela. En reprenant l’idée de Gusteau, on dirait que le mantra du moment dans le logiciel est devenu « Tout le monde peut coder », grâce à l’IA générative et au vibe coding. Et, comme chez Gusteau, il y a une part de vérité. L’intelligence artificielle (IA) a abaissé les barrières. Les prototypes se construisent en quelques heures. Le code se génère, se teste, se réécrit.

La promesse n’est pas fausse.

Elle est incomplète.

Le conte de fées du développeur à 20 dollars par mois touche à sa fin. Et le réveil coûte cher.

Pour paraphraser Gusteau : « Tout le monde peut coder. » Mais vu l’évolution des coûts des outils d’IA en 2026, « seuls les riches peuvent être grands ».

Le récit « l’IA remplace le travail » change de ton

#

2026 pourrait rester comme l’année du « remplacement silencieux ». Il ne se passe presque plus une semaine sans qu’un géant de la tech annonce une restructuration profonde. Mais contrairement à la crise post-pandémie de 2023, le coupable a aujourd’hui un nom précis : l’efficacité par l’IA.

Depuis deux ans, nous entendons la même promesse sous différentes formes : équipes plus petites, développeurs « 10x », entreprises gérées par une poignée de personnes, agents autonomes capables de faire le travail de départements entiers. Une partie de cette promesse est réelle. L’automatisation comprime certaines activités intellectuelles, et beaucoup d’entreprises réorganisent effectifs et processus autour de l’IA.

Mais dire « l’IA vole le travail » est un raccourci. La réalité est plus inconfortable et plus intéressante : l’IA devient un levier pour redessiner les rôles, les attentes, les budgets et les responsabilités. Parfois, elle remplace des tâches. Parfois, elle augmente la pression sur les personnes qui restent. Parfois, elle devient le langage avec lequel le management raconte une réduction des coûts qui a aussi d’autres causes.

Les exemples racontent différentes nuances du même mouvement. Chez Cisco, l’IA ressemble surtout à une réallocation de capital : près de 4 000 suppressions de postes, moins de 5 % des effectifs, pendant que l’entreprise déplace ses investissements vers l’infrastructure IA et les zones de croissance associées.¹ Meta est un cas plus délicat : Reuters a évoqué des suppressions potentielles supérieures à 20 % dans un contexte de hausse des coûts IA et data centers, mais l’entreprise a qualifié l’article de « speculative reporting about theoretical approaches ».² La prudence est donc indispensable : pas de « licenciements causés par l’IA », mais une IA qui entre dans le débat sur l’efficacité, l’infrastructure et le dimensionnement organisationnel.

D’autres cas emploient un langage plus direct. Cloudflare a lié environ 1 100 suppressions de postes à l’usage interne de l’IA, en hausse de plus de 600 % en trois mois, malgré un trimestre record.³ PayPal parle de modernisation de la plateforme et d’adoption agressive de l’IA dans le développement, dans le cadre d’une réorganisation plus large avec des économies attendues importantes.⁴ DeepL, enfin, est peut-être l’exemple le plus explicite : environ 250 suppressions, un quart des effectifs, et une « massive structural shift » sur le type de travail qui existe, qui le fait, et combien de personnes sont nécessaires.⁵

Le schéma est clair : nous ne regardons pas un simple remplacement homme-machine.

Sources : Reuters, TechCrunch, Heise/tech.eu — mars/mai 2026

Le vrai problème, ce n’est pas l’IA, c’est la facture

#

La partie la plus sous-estimée de l’histoire est économique.

Ces derniers temps, nous avons vendu l’IA comme s’il s’agissait d’un logiciel traditionnel : un prix mensuel, une licence, quelques limites d’utilisation. Mais les modèles génératifs ne sont pas un SaaS classique. Chaque requête consomme du calcul. Chaque sortie a un coût. Chaque fenêtre de contexte plus grande entraîne plus de tokens. Chaque agent qui lit des fichiers, appelle des outils, fait des retries et attend des tests consomme des ressources, même lorsque nous avons l’impression qu’il « travaille tout seul ».

GitHub l’a dit en annonçant le passage de Copilot à une facturation à l’usage à partir du 1er juin 2026. Les prix de base ne changent pas, mais les premium request units sont remplacées par des GitHub AI Credits consommés selon les tokens d’entrée, de sortie et de cache. La motivation officielle est claire : Copilot est devenu une plateforme agentique capable de sessions longues et multi-étapes, avec des besoins de compute et d’inférence beaucoup plus élevés.⁶

C’est un tournant culturel. Tant que le prix semblait forfaitaire, une conversation rapide et une session agentique de deux heures semblaient appartenir au même abonnement. Dès que la facturation suit les tokens, les modèles et la consommation réelle, la différence devient visible.

Anthropic rend le phénomène encore plus concret dans la documentation officielle de Claude. Les prix API sont exprimés par million de tokens, avec des écarts importants entre modèles, entrée, sortie et cache. Claude Opus 4.7, publié le 16 avril 2026, est listé à 5 dollars par million de tokens d’entrée et 25 dollars par million de tokens de sortie ; Claude Sonnet 4.6 à 3 et 15 dollars ; Haiku 4.5 à 1 et 5 dollars.⁷ Jusque-là, rien de surprenant.

La partie intéressante arrive dans les détails : le nouveau tokenizer d’Opus 4.7 peut utiliser jusqu’à 35 % de tokens en plus pour le même texte ; les endpoints régionaux peuvent avoir un premium de 10 % ; la résidence des données aux États-Unis peut appliquer un multiplicateur 1,1x ; le fast mode peut monter à 6x ; les outils ajoutent des tokens ; la recherche web coûte 10 dollars pour 1 000 recherches ; les agents managés incluent aussi un runtime à 0,08 dollar par session-heure.⁷

Sources : Anthropic API Pricing, GitHub Blog — avril/mai 2026

Pris séparément, ces chiffres semblent faibles. Multipliés par les développeurs, les workflows CI/CD, la documentation interne, le support client, les agents de sécurité, l’analyse de logs et les retries automatiques, ils deviennent une ligne budgétaire sérieuse.

Le Financial Times a titré que les 725 milliards de dollars de dépenses IA des Big Tech poussent le free cash flow à son plus bas niveau depuis dix ans.⁸ Même sans entrer dans tous les détails, le message est évident : l’IA « bon marché » pour l’utilisateur final repose sur une infrastructure très coûteuse pour ceux qui la fournissent.

C’est ici que la métaphore du livre de cuisine redevient utile. Au début, le livre de recettes vous fait croire que vous pouvez cuisiner ; puis vous découvrez qu’il faut des ingrédients, du matériel de plus en plus cher, de l’énergie et du temps. Mais pour un plat vraiment exceptionnel, il faut encore le chef : celui qui sait distinguer un code qui « fonctionne » d’un code solide, sûr et prêt à être servi.

Vibe coding : utile, rapide, mais pas magique

#

J’utilise des outils d’IA générative, y compris pour coder, tous les jours. Et oui, ils fonctionnent.

Dans le détail, le vibe coding fonctionne très bien pour les prototypes, le boilerplate, les refactorings contrôlés, la documentation, les scripts temporaires, le parsing de logs, les premières interfaces et la traduction d’idées en code testable. Si je dois préparer une démo CIAM, une proof of concept ou un lab, je démarre aujourd’hui beaucoup plus vite qu’il y a quelques années. Un exemple concret est le projet Opaflix : il n’est pas né en quelques heures, mais grâce au vibe coding, j’ai pu le réaliser en quelques jours ou semaines plutôt qu’en plusieurs mois, même si je ne suis pas développeur full-time.

Mais « plus rapide » ne veut pas dire « sans supervision ».

En pratique, je ne délègue souvent pas à l’IA. Je joue en même temps le rôle de product manager, architecte, security reviewer et QA. Je dois expliquer le contexte, limiter le périmètre, empêcher les réécritures inutiles, vérifier qu’elle n’invente pas d’API et l’arrêter lorsqu’elle décide « d’améliorer » des parties que personne ne lui avait demandé de toucher.

L’IA perd le contexte. Elle ressemble à un stagiaire très rapide, mais sans mémoire stable : à chaque fois, elle doit relire le code, les README, AGENTS.md ou CLAUDE.md. Et chaque rechargement de contexte consomme des tokens.

Un désastre de sécurité potentiel

#

La partie la plus dangereuse, c’est que le code généré semble souvent plausible. Il n’est pas cassé de manière évidente. Il compile. La démo tourne. L’interface répond. Et c’est précisément pour cela qu’il peut passer sous le radar.

Cela m’est arrivé de manière très concrète. Je réalisais une démo de site web pour un projet CIAM client. J’avais besoin d’un exemple d’intégration de reset password en full code, sans utiliser le widget prêt à l’emploi d’Okta. J’ai demandé à l’IA de générer un exemple, et elle m’a rendu du code fonctionnel.

Fonctionnel, oui, mais complètement vulnérable.

Il suffisait de passer un username dans la query string pour changer le mot de passe de n’importe quel utilisateur, sans aucune vérification. Le backend récupérait ce username et utilisait le SDK et l’API Okta pour définir le nouveau mot de passe. Pas de token de récupération, pas de vérification out-of-band, pas de contrôle de l’identité du demandeur, pas de protection sérieuse contre l’abus ou l’énumération.

C’était le genre de code qui peut paraître parfait dans une démo superficielle. En production, cela aurait été un désastre.

C’est le point que voient immédiatement celles et ceux qui travaillent en IAM et CIAM : l’authentification n’est pas seulement « un formulaire qui fonctionne ». Le reset password est l’un des flux les plus sensibles d’un système d’identité. Il doit être conçu avec preuve de possession, rate limiting, audit, policy, tokens temporaires et séparation nette entre demande et action. L’IA peut aider à écrire du code, mais elle ne peut pas remplacer le jugement de sécurité si vous ne lui donnez pas contraintes, contexte et revue.

C’est pourquoi je ne m’inquiète pas de voir des plateformes comme Okta remplacées par un prompt d’IA générative. Générer du code est une chose ; concevoir, tester, protéger et maintenir en production un service de gestion des identités en est une autre. Sécurité, fiabilité, auditabilité et responsabilité opérationnelle ne s’improvisent pas avec une réponse bien formatée.

Le coût de vraiment utiliser l’IA

#

J’ai aussi vu l’autre côté économique. Entre février/mars et avril/mai, mes coûts personnels et professionnels liés à l’IA ont augmenté d’environ 25 à 30 fois. Pas parce que je faisais des choses absurdes, ni parce que j’avais radicalement changé ma façon de travailler : la façon de compter les tokens a changé, le prix des tokens a changé, et les sessions agentiques pèsent plus lourd économiquement. Et bien sûr, je ne suis pas le seul à avoir vécu cela : beaucoup ont constaté des hausses vertigineuses des coûts.⁹

C’est tout le problème de la gestion des coûts de l’IA : la consommation augmente non pas quand on « joue » avec l’IA, mais quand on commence à l’utiliser vraiment. Et c’est là que la blague devient moins drôle : avec ces dynamiques, le vibe coding risque vraiment de devenir soutenable seulement pour ceux qui peuvent se le permettre.

Le travail humain n’est pas seulement de l’output

#

Le remplacement complet des équipes humaines est souvent présenté comme un problème de productivité : si un agent produit le même output que cinq personnes, alors je peux réduire l’équipe. Mais dans les organisations réelles, le travail n’est pas seulement de l’output.

Le travail, c’est de la mémoire historique. C’est savoir pourquoi un système a été construit d’une certaine manière. C’est se souvenir de ce client qui a une configuration différente parce qu’il y a eu, des années plus tôt, une migration incomplète. C’est savoir qu’une policy apparemment redondante existe à cause d’un audit passé. C’est connaître les « trucs du métier » que personne n’a documentés parce qu’ils semblaient évidents pour ceux qui étaient là.

Cette connaissance implicite est extrêmement difficile à transférer à un modèle. Non pas parce que l’IA est stupide, mais parce qu’elle n’existe souvent pas sous forme documentée. Elle est distribuée entre personnes, chats, tickets, calls et exceptions temporaires devenues permanentes.

Il y a aussi un autre point humain, souvent ignoré : il n’est pas évident que les personnes aient envie d’entraîner sereinement le système qui pourrait réduire leur rôle demain. La collaboration avec l’IA exige de la confiance. Si l’IA est introduite uniquement comme levier de réduction des coûts, cette confiance se brise.

Beaucoup d’entreprises sous-estiment aussi le coût de la supervision. Certaines analyses du vibe coding parlent désormais de Quality Tax : des heures senior passées à maintenir les tests, vérifier le code généré et corriger des sorties qui semblaient prêtes.¹⁰ Un agent qui produit dix pull requests par jour ne supprime pas forcément du travail : il peut le déplacer vers la revue, la sécurité, l’architecture et la gouvernance.

L’IA est un multiplicateur : si vous multipliez par zéro, vous obtenez zéro ; si vous multipliez par une équipe experte, vous obtenez des résultats. Mais ce pouvoir a un prix, et les entreprises qui contrôlent ces outils détiennent aussi les clés des coûts.

Le livre de recettes peut vous aider à commencer.

Mais quelqu’un doit encore goûter le plat avant de le servir.

Les erreurs récentes ne relèvent pas de la science-fiction

#

Quand on parle de risques IA, inutile d’imaginer des scénarios apocalyptiques. Les incidents opérationnels et de sécurité déjà visibles suffisent.

GitHub, dans son rapport de disponibilité d’avril 2026, a documenté des incidents qui ont aussi touché Copilot. Le 9 avril, Copilot coding agent a subi des retards au démarrage de nouvelles sessions : environ 84 % des nouvelles demandes étaient retardées, avec des pics d’attente de 54 minutes contre une baseline de 15 à 40 secondes, et environ 22 700 créations de workflows retardées ou échouées. La cause était un bug de rate limiting, aggravé par un trafic API 3 à 4 fois plus élevé après une mise à jour client.¹¹

Le 22 avril, Copilot Chat sur github.com et Copilot Cloud Agent ont été indisponibles à cause d’un problème de configuration d’infrastructure qui a provoqué des soucis de connectivité avec les bases de données.¹¹ Encore une fois : ce n’est pas la fin du monde. Mais si une entreprise décide de baser sa delivery sur des agents IA, ces incidents deviennent une partie du risque opérationnel.

Côté sécurité, les exemples concrets commencent à s’accumuler. En mars 2026, Meta a dû gérer des agents internes qui auraient exposé des données sensibles à des employés non autorisés.¹² En mai 2026, le cas PocketOS a montré un risque encore plus opérationnel : un coding agent basé sur Claude aurait supprimé des bases de données de production et des backups en quelques secondes.¹³

OWASP, avec le GenAI Security Project, inclut explicitement les LLM, les systèmes agentiques et les applications pilotées par l’IA dans le périmètre des pratiques de secure development et de gouvernance.¹⁴ Ce n’est pas un détail : quand les agents peuvent appeler des outils, lire des données, écrire du code, ouvrir des tickets, modifier des configurations ou exécuter des workflows, ce ne sont plus des « chatbots ». Ce sont des acteurs opérationnels.

Qui contrôle les fourneaux ?

#

Ma conclusion n’est pas anti-IA.

L’IA n’est pas du bluff. Les progrès sont réels, les gains de productivité sont réels, et l’ignorer serait irresponsable. Mais il serait tout aussi irresponsable d’accepter sans esprit critique l’idée que remplacer des équipes humaines par des agents soit toujours moins cher, plus sûr ou plus efficace.

Aujourd’hui, le remplacement complet déplace souvent les coûts au lieu de les supprimer : tokens, inférence, plateformes, gouvernance, revue, incident response et supervision. Il n’augmente pas automatiquement la qualité, parce que la qualité exige contexte, tests, sécurité et connaissance du domaine. Et il introduit de nouveaux risques, parce que chaque agent qui agit pour notre compte a une identité, des privilèges et des responsabilités.

Pour celles et ceux qui, comme moi, travaillent dans l’IAM, la direction est claire : les agents IA sont des identités. Ils doivent être gouvernés comme des identités — j’ai approfondi le sujet dans le blueprint pour une entreprise agentique sécurisée et les patterns d’accès pour agents IA avec Okta. Il faut savoir qui les a créés, quel humain les sponsorise, quelles données ils peuvent lire, quelles actions ils peuvent exécuter, quand ils doivent être désactivés et comment ils sont audités.

Least privilege, policy, logging, lifecycle, approbations, segregation of duties et compliance ne deviennent pas moins importants avec l’IA. Ils deviennent plus importants. L’EU AI Act va dans le même sens : approche fondée sur le risque, logging, transparence, supervision humaine, cybersécurité et obligations spécifiques pour les systèmes à haut risque et les modèles à usage général.¹⁵

La partie sécurité peut, au moins en théorie, être traitée avec gouvernance, identité, policy, audit et outils adaptés. L’incertitude la plus difficile reste celle des coûts croissants : tokens, compute, modèles premium et tarification de plus en plus liée à la consommation réelle.

C’est peut-être le point le plus important. Les entreprises qui contrôlent les modèles, les prix, l’infrastructure et l’accès au compute auront un pouvoir énorme sur notre façon de travailler. Pas seulement parce qu’elles vendent des outils, mais parce qu’elles deviennent une partie de la chaîne de production du logiciel, du support, de la compliance et de la connaissance d’entreprise. Par conséquent, chaque hausse de prix qu’elles imposeront pourra avoir des effets très concrets sur les budgets.

Peut-être que la phrase « tout le monde peut coder, mais seuls les riches peuvent être grands » est trop cynique, mais elle saisit quelque chose de réel.

L’IA peut abaisser la barrière d’entrée. Elle peut aider davantage de personnes à créer. Elle peut rendre l’expérimentation plus accessible. Pour revenir à Ratatouille : « Tout le monde ne peut pas devenir un grand artiste. Mais un grand artiste peut surgir n’importe où. »

Mais devenir vraiment bon exigera encore compétence, jugement, contexte, responsabilité et ressources économiques pour payer les tokens et l’accès à ces outils.

Quelle est votre expérience des coûts IA, de la productivité IA et du développement avec des agents IA ? Voyez-vous plus de productivité réelle ou plus de complexité à gouverner ? Écrivez-moi dans les commentaires ou sur LinkedIn.