Vibe Coding : La menace cachée de l'IA en tant que Shadow IT pour les entreprises
Le “vibe coding”, un nouveau terme en vogue dans le monde de la technologie, décrit le processus de génération de logiciels en sollicitant conversationnellement un agent d’intelligence artificielle. Son promoteur, Andrej Karpathy, a célèbrement caractérisé cette approche comme « pas vraiment du codage – je vois juste des choses, dis des choses, exécute des choses et copie-colle des choses, et ça marche la plupart du temps », la jugeant adaptée aux « projets de week-end jetables ». Un différenciateur clé du vibe coding par rapport aux autres méthodes assistées par l’IA est l’acceptation non critique du code produit par l’agent. Cela permet aux « développeurs citoyens », ceux sans formation formelle en programmation, de créer des applications à petite échelle sans avoir besoin de comprendre le code sous-jacent ou son fonctionnement.
Cette vision s’aligne sur une ambition de longue date : définir des logiciels en utilisant l’anglais simple comme langage de programmation. Bien que la résolution de défis mineurs avec des logiciels puisse être satisfaisante, à l’image d’une réparation domestique réussie, son application dans un contexte d’entreprise ressemble étrangement non pas au développement logiciel traditionnel, mais au phénomène problématique connu sous le nom de Shadow IT.
Le Shadow IT apparaît lorsque les unités commerciales, frustrées par la lenteur des projets informatiques officiels, prennent les choses en main. Sous la pression de gérer des charges de travail croissantes, elles se tournent souvent vers des « héros du business » qui bricolent des solutions provisoires à l’aide d’outils facilement disponibles comme des feuilles de calcul ou des bases de données, contournant fréquemment les processus d’approvisionnement officiels. Bien que ces solutions ad hoc offrent un soulagement localisé et temporaire, elles fournissent rarement une réponse durable à long terme. Le plus souvent, leur « succès » réside dans la nécessité de reprioriser d’urgence le projet original, généralement après l’échec inévitable de la solution Shadow IT.
Le véritable développement logiciel englobe bien plus que la simple création de fonctionnalités ; il nécessite une considération rigoureuse des exigences non fonctionnelles. Celles-ci incluent des aspects cruciaux tels que l’évolutivité, les obligations légales et réglementaires, la sécurité, l’expérience utilisateur, l’accessibilité et la reprise après sinistre. Le vibe coding, tout comme le Shadow IT, contourne largement ces préoccupations critiques, car les développeurs citoyens sont peu susceptibles d’en être conscients, et encore moins de demander à l’IA de les aborder. Lorsque de tels systèmes échouent inévitablement, le même « héros du business » qui a défendu le projet Shadow IT devient souvent le méchant, piégé dans un cycle incessant de corrections alors qu’il lutte pour maintenir le système opérationnel. Le même sort attend les applications nées du vibe coding.
Une idée fausse très répandue dans le développement logiciel est la croyance que quelqu’un sait précisément ce que le logiciel doit faire, ne nécessitant qu’un codeur pour l’implémenter. Comme Fred Brooks l’a élucidé dans son article séminal de 1987, « No Silver Bullet » (Pas de balle d’argent) : « La partie la plus difficile de la tâche logicielle est d’arriver à une spécification complète et cohérente, et une grande partie de l’essence de la construction d’un programme est en fait le débogage de la spécification. »
Pour les organisations d’entreprise, le vibe coding introduit quatre domaines de risque critiques, souvent résumés par quatre mots commençant par « S » : Spécification, Scalabilité, Software Design (Conception logicielle) et Sécurité/Conformité. Ensemble, ils ressemblent à un pneu métaphorique qui se dégonfle lentement.
Premièrement, la Spécification : Des décennies d’expérience nous ont appris l’immense difficulté de définir précisément les exigences d’un système logiciel en amont. Nous saisissons souvent les cas d’utilisation primaires, mais découvrons une multitude de scénarios imprévus pendant le développement. La création de logiciels réussie implique généralement soit de cultiver une compréhension approfondie des besoins des utilisateurs, soit de livrer de manière itérative de petits changements rapides pour expérimenter vers le succès. Les meilleures équipes combinent les deux. Le vibe coding, par sa nature même, exacerbe les faiblesses de la spécification, conduisant à des exigences fonctionnelles et non fonctionnelles manquées. Lorsque celles-ci sont identifiées plus tard, les changements subséquents peuvent involontairement casser des fonctionnalités qui fonctionnaient auparavant, ramenant efficacement la livraison logicielle à une ère ad hoc de « code-and-fix ». De plus, expliquer comment un système fonctionne est souvent essentiel, en particulier pour la conformité réglementaire concernant la prise de décision automatisée. Avec un logiciel développé en mode « vibe coding », la seule « documentation » pourrait être les invites conversationnelles initiales, qui peuvent ne pas refléter précisément le comportement réel du code généré, nécessitant finalement une inspection et une compréhension humaines.
Deuxièmement, la Scalabilité : Au-delà de la performance directe du système, le logiciel d’entreprise exige un processus de développement évolutif. Cela nécessite une collaboration entre plusieurs développeurs pour atténuer les risques, favoriser une compréhension partagée et assurer une croissance des capacités à long terme. Cette compréhension partagée est construite grâce à la documentation et, surtout, grâce au code écrit dans un langage de programmation lisible par l’homme. Les équipes de développement modernes élaborent du code facile à comprendre et valident le comportement du système avec des spécifications exécutables, qui servent de documentation ultime et dictent en grande partie les coûts de maintenance – souvent plusieurs fois le coût d’implémentation initial. Le vibe coding, cependant, n’offre que des flux conversationnels ou des résumés d’IA comme « documentation », aucun d’entre eux ne fournissant une description précise du système. Bien que le code brut soit accessible, même les programmeurs expérimentés peuvent avoir du mal à déchiffrer le code source généré par l’IA, ce qui pose des défis importants pour la collaboration, les revues de code et la résolution des conflits de fusion entre des individus peu familiers avec sa structure idiosyncratique. Ni le logiciel ni le processus de développement ne s’adaptent efficacement avec le vibe coding.
Troisièmement, la Conception logicielle : La conception architecturale d’un logiciel est toujours importante et peut même devenir un avantage concurrentiel critique, permettant des capacités organisationnelles uniques. Ces décisions de conception, distinctes des exigences fonctionnelles, influencent profondément la facilité avec laquelle le logiciel peut s’adapter aux besoins futurs. En vibe coding, la conception est largement une réflexion après coup. L’attente pourrait être que l’ensemble du système puisse être régénéré par l’IA si les principes de conception sont invalidés par de nouvelles exigences. Cependant, cela nécessiterait un mécanisme pour s’assurer que toutes les instructions antérieures sont fidèlement reportées, à l’image d’un jeu de société où les joueurs doivent se souvenir d’une liste d’éléments toujours croissante. Pour les projets « jetables », les préoccupations de conception sont minimes, mais pour les systèmes à long terme, les coûts de maintenance éclipseront le développement initial. Ignorer la conception rend le contrôle de cette courbe de coûts presque impossible, rendant le logiciel économiquement non viable.
Enfin, la Sécurité et la Conformité : Les entreprises sont confrontées à d’immenses charges en matière de sécurité et de conformité. Les développeurs des grandes organisations sont bien familiarisés avec la sécurisation des accès, la protection des données et le respect des exigences d’audit (par exemple, ISO:27001). Tout au long du pipeline de développement, des référentiels de code au déploiement, des outils et des techniques garantissent la conformité. Réconcilier le vibe coding avec ces exigences d’audit rigoureuses est profondément difficile. Un travail supplémentaire significatif serait nécessaire pour démontrer que le code généré par l’IA a été vérifié avec la même rigueur que le code écrit par des humains, examiné par des pairs et basé sur les spécifications du produit. Le modèle économique du temps de développeur « économisé » doit être mis en balance avec la validation considérablement accrue nécessaire pour garantir que le code est sécurisé, exempt de vulnérabilités cachées et conforme. Le coût de la compilation des exigences à partir des seules invites conversationnelles pourrait facilement dépasser les économies de développement perçues, tout en augmentant simultanément les risques de perte de données, de violations et de dommages à la réputation.
L’attrait du vibe coding pour les entreprises provient d’une combinaison dangereuse de fausses hypothèses, en particulier la notion qu’il réduira les coûts de développement. Comme Dan Garfield, vice-président de GitOps et Open Source chez Octopus, le dit si bien : « Le plus grand défi du vibe coding en entreprise n’a rien à voir avec la qualité des modèles, ou l’inexpérience potentielle des ingénieurs. C’est que le vibe coding augmente exponentiellement l’importance des tests et de la réduction des risques de la livraison logicielle tout en augmentant simultanément le volume des changements au-delà du point de rupture. »
Les hypothèses sous-jacentes sont courantes mais fondamentalement erronées :
Hypothèse : La valeur créée pendant le développement logiciel est uniquement le code lui-même.
Réalité : La vraie valeur réside dans la connaissance incarnée par le code et, surtout, par les développeurs qui le comprennent et le maintiennent.
Hypothèse : Créer une application est la partie la plus coûteuse.
Réalité : Maintenir une application tout au long de son cycle de vie est souvent beaucoup plus coûteux.
Hypothèse : Générer du code fait gagner du temps.
Réalité : Générer du code ne fait que déplacer la charge du codage vers d’autres activités, souvent plus complexes, comme les tests intensifs, les revues approfondies et les audits rigoureux.
Pour la livraison de logiciels d’entreprise, ces fausses hypothèses ouvrent une voie directe vers des problèmes futurs, transformant un raccourci perçu en un détour coûteux.