97 % des développeurs utilisent l’IA : le « vibe coding » change le pouvoir

Le terme « vibe coding », lancé par Andrej Karpathy, a été consacré mot de l’année par le dictionnaire Collins. Parallèlement, une étude GitHub indique que plus de 97 % des développeurs d’entreprises utilisent déjà l’IA pour coder. Cette évolution remet en cause le monopole de faisabilité des équipes d’ingénierie, en s’appuyant sur l’asymétrie d’information et des précédents comme l’édition de bureau.

Une pratique nommée et mesurée, des mots aux usages

Neuf mois après son apparition, « vibe coding » a été désigné mot de l’année par le dictionnaire Collins. L’expression a été popularisée en février 2025 par Andrej Karpathy, membre fondateur d’OpenAI, pour décrire un mode de travail où l’on formule une intention à une IA, on accepte sa proposition et un résultat fonctionnel émerge sans lire en détail le code. Karpathy présentait ce terme de façon légère, à propos d’un projet de week-end. Dans le même temps, l’usage s’ancre dans les entreprises : en 2024, Kyle Daigle et l’équipe de recherche de GitHub ont sondé deux mille développeurs d’entreprises aux États-Unis, au Brésil, en Inde et en Allemagne, et plus de 97 % déclaraient utiliser des outils de codage IA au travail. L’adoption n’est plus décrite comme une tendance émergente mais comme un état de fait généralisé.

Quand la faisabilité cesse d’être un veto réservé

Des profils non techniques peuvent désormais produire rapidement des prototypes opérationnels. Un fondateur peut, un vendredi, mobiliser Claude, Cursor ou Figma Make et, d’ici lundi, obtenir une version approximative d’une fonctionnalité initialement estimée à trois semaines, suffisante pour appuyer une démonstration. Une designer à qui l’on avait opposé la difficulté technique peut construire une version, parfois avec un code médiocre, et la livrer. Selon l’auteur, l’intelligence artificielle démantèle le monopole de l’ingénierie, dont l’autorité demeurait réelle mais n’est plus l’unique barrière entre une idée et une version fonctionnelle. Être le seul à rendre un produit réel permettait d’imposer délais et impossibilités : cette capacité de blocage se relativise lorsque d’autres obtiennent des résultats utilisables.

Le pouvoir d’expert reposait sur l’illisibilité du code

La production logicielle a longtemps été difficilement contestable de l’extérieur : la complexité du code rendait le travail illisible pour les non‑ingénieurs, tandis que maquettes et parcours pouvaient être débattus par tous. Des objections techniques comme une condition de course, un schéma cassé ou un couplage à la couche d’authentification pouvaient clore une discussion sans vérification possible. John French et Bertram Raven ont décrit en 1959 le pouvoir d’expert comme une base informelle du pouvoir, indépendante des titres. Un CTO pouvait ne pas décider de la stratégie, du client ou du budget, tout en détenant des réponses techniques que d’autres ne pouvaient pas aisément vérifier.

Une asymétrie décrite par Akerlof et illustrée par Poe

George Akerlof a montré en 1970, à propos du marché des voitures d’occasion, que l’asymétrie d’information donne un fort levier à celui qui sait distinguer les « citrons ». Les équipes logicielles ont fonctionné sur une asymétrie comparable, où les codeurs qualifiaient ce qui était acceptable. L’auteur rapproche aussi cette dynamique de « La lettre volée » d’Edgar Allan Poe, où un objet caché en évidence reste introuvable car on suppose l’accès difficile. Jacques Lacan a soutenu que ce n’est pas tant le contenu qui compte que l’emprise de l’objet sur ceux qui le poursuivent, une emprise que l’auteur compare à la dynamique autour d’un ticket Jira. Selon lui, pendant environ trente ans, l’invérifiable dans le code est resté non vérifié, laissant prospérer des affirmations non testées.

Des précédents : l’édition de bureau et la littératie en design

À la fin des années 1980, l’édition de bureau a donné à des particuliers équipés d’un Macintosh et d’une imprimante laser des capacités autrefois réservées aux imprimeries et spécialistes, déclenchant une panique dans l’édition. À l’ère d’Internet, certains clients arguaient qu’un proche utilisateur de Photoshop pouvait concevoir un logo. La généralisation des outils n’a pourtant pas supprimé la profession : Rebecca Kelly souligne que la littératie en design ne s’est pas diffusée avec les logiciels. Peu de personnes pouvaient ouvrir l’outil et produire un bon résultat. La valeur s’est déplacée vers le jugement, et ceux qui ont cessé de protéger l’accès à l’outil pour vendre leur expertise ont prospéré. L’auteur anticipe une trajectoire similaire pour l’ingénierie.

Retour d’expérience et position initiale du pouvoir

L’auteur relate avoir travaillé comme architecte de l’information sur un projet d’entreprise dont les spécifications et fonctionnalités étaient fixées en amont. Après trois semaines d’itérations, la présentation a été interrompue à la troisième maquette sur environ cent vingt, des objections d’ingénierie déclarant des éléments hors périmètre, non faisables dans le calendrier ou inadaptés. Ni client ni hiérarchie ne décidaient réellement de ce qui serait livré : l’ingénierie détenait ce pouvoir, et un refus empêchait la construction. Cette position s’expliquait par la maîtrise de la faisabilité — « pouvons‑nous le construire et en combien de temps » — telle que nommée par Marty Cagan, inscrite dans une logique de contrainte au sens d’Eliyahu Goldratt. Historiquement, cette faisabilité appartenait à l’ingénierie, un quasi‑veto sur le réel produit. Le pouvoir n’était pas tiré de la stratégie ni de la présence aux premières réunions, mais du monopole d’exécution, adossé à la difficulté intrinsèque du logiciel, acquise au prix d’années d’apprentissage et d’incidents nocturnes.

Un imaginaire populaire convoqué pour traduire l’écart

Le contraste entre impossibilité affichée et réalisation effective est illustré par une scène d’Iron Man où Obadiah Stane rappelle que Tony Stark a construit un dispositif « dans une grotte, avec une boîte de déchets ». L’auteur met en parallèle l’accélération lexicale de « vibe coding » vers une consécration lexicographique en moins de temps que bien des entreprises ne livrent une fonctionnalité, pour souligner l’écart entre discours d’impossibilité et preuves rapides par le prototype.