Vibecoding et Sécurité : Ce que les dirigeants doivent savoir sur les équipes qui construisent avec l’IA
Écart de connaissances sur l’IA: Les dirigeants sont confrontés à des défis lorsque les membres de l’équipe maîtrisent mieux qu’eux les outils et capacités de l’IA.
Vibecoding expliqué: Les employés non techniques créent des outils fonctionnels via des demandes, comblant ainsi le fossé entre idée et exécution.
Préoccupations de sécurité: Des outils de vibecoding non gérés exposent l’organisation à des risques de gestion et d’exposition de données, en particulier des vulnérabilités liées aux données personnelles.
Conséquences financières: Une utilisation non optimisée des outils d’IA peut entraîner des dépenses inattendues et des risques financiers.
Problèmes de passage à l’échelle: Les outils de vibecoding performants nécessitent une supervision professionnelle pour garantir leur évolutivité et leur fiabilité.
Soyons honnêtes : nous sommes tous à des stades différents en matière d'IA. Et pour les dirigeants, cela peut être déstabilisant — plus que jamais, les subordonnés surpassent leurs managers en connaissances et en maîtrise de l'IA, avancent rapidement, et cassent souvent des choses.
Alors que de nombreuses organisations encouragent l'exploration ouverte des outils d'IA, le vibecoding — la prochaine étape de l'appropriation de l’IA pour beaucoup d’employés non techniques — est une aventure qui comporte différents niveaux de risque, selon ce que vous construisez, pour qui vous le construisez, et quelles données sont stockées et utilisées.
Cela devient particulièrement répandu au sein des équipes de gestion de projet et d’opérations, où la création d’outils propriétaires est souvent la solution évidente face aux besoins de processus — et avec les agents de codage IA, il n’a jamais été aussi facile de donner le feu vert.
Unlock for Free
Create a free account to finish this piece and join a community of forward-thinking leaders unlocking tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
Pour nous aider à comprendre sur quoi rester vigilants lorsque les équipes commencent à construire, j’ai fait appel à Tim Fisher, VP IA chez DPM, pour nous en donner un aperçu. Cet article s’adresse à tous ceux qui ont déjà reçu un « Hé patron, regarde ce super truc que j'ai fait avec Claude ! » — nous espérons qu’il vous sera utile.
D'abord, qu’est-ce que le vibecoding ? Et pourquoi est-ce réellement précieux ?
Pour les besoins de cet article, le vibecoding désigne le codage via du prompting — spécialement par quelqu'un de non technique. C’est distinct d’un développeur logiciel utilisant un outil comme GitHub Copilot, où l’humain apporte encore de réelles connaissances techniques au travail. Ici, on parle du directeur financier, du coordinateur des opérations, du chef de projet qui n’a jamais écrit une ligne de code, et qui livre maintenant des outils fonctionnels en utilisant uniquement des consignes en langage naturel.
Et le point de vue initial de Fisher pourrait vous surprendre : il en est réellement enthousiaste. « J’adore l’idée que des personnes qui ne savent pas coder puissent enfin sortir ce qu’elles ont en tête sous une forme que tout le monde peut voir, utiliser et avec laquelle jouer », dit-il. « C’est une manière de communiquer qui n’existait pas auparavant. » Il le considère moins comme une capacité technique que comme un nouveau support de communication — qui comble l’écart entre l’idée et l’exécution pour des personnes qui ont toujours eu des idées mais qui manquaient du vocabulaire technique pour les exprimer.
Le vibecoding est une manière de communiquer qui n’existait pas auparavant.
« C’est un peu comme les défis que rencontrent les gens lorsqu’ils travaillent avec des équipes de design, » explique Fisher. « Je ne sais pas dessiner un bonhomme allumette. Et donc, quand je veux communiquer quelque chose de visuel à quelqu’un, je suis ravi qu’il existe aujourd’hui des outils qui me permettent d’expliquer en détails, avec des mots soigneusement choisis — ce en quoi je suis doué — et d’obtenir à la sortie quelque chose qu’une autre personne, qui sait concevoir, se dira : ‘Ah, je vois ce que tu veux vraiment.’ »
Pour les dirigeants, ce changement de perspective est important. L’impulsion de tout arrêter rate le vrai intérêt : le vibecoding peut accélérer l’alignement, faire émerger plus vite les idées, et offrir aux collaborateurs non techniques un nouveau moyen de contribuer. La question n’est pas de l’autoriser ou non. C’est de savoir si vous comprenez ce qu’il se passe après que l’outil a été construit.
Où s’arrête la valeur — et où commencent les risques
Fisher prend soin de distinguer la phase de « communication » du vibecoding de ce qui tend à la suivre — et c’est là que son ton change. « Je pense que la valeur s’arrête probablement ici, la plupart du temps, » dit-il. « C’est une bien meilleure manière de transmettre des idées et une orientation. Mais ce que l’on constate, c’est que certaines choses peuvent se produire ensuite qui vont au-delà du simple ‘Regarde, je t’ai communiqué une idée, nous partageons désormais un langage’. Et là, ça devient inquiétant. »
Le problème n’est pas dans le prompting. Il est dans le déploiement. C’est le moment où un prototype devient un outil utilisé par de vraies personnes, qui stocke de vraies données, qui tourne sur une véritable infrastructure — et la personne qui l’a créé ne sait toujours pas ce qui se passe « sous le capot ».
Les vulnérabilités de sécurité que les dirigeants doivent connaître
PII et gestion des données
Le risque le plus intuitif pour la plupart des responsables tournera autour des informations personnellement identifiables (PII). Fisher utilise un exemple concret pour illustrer où se situe la limite : « Je pense que la complexité maximale serait juste avant l’ingestion des données d’employés ou de clients dans un système qui les régurgite auprès d’autres personnes. C’est là que les questions PII entrent en jeu. »
Je pense que le seuil de complexité serait juste avant l’intégration des données d’employés ou de clients dans un système qui régurgite ces données à d’autres personnes.
Le risque augmente avec la sensibilité des données et le public qui peut y accéder — et dans les équipes d’opérations et de gestion de projet, ces données incluent souvent des informations clients, des dossiers d’employés, des données sur les rémunérations ou des coordonnées qui présentent un véritable risque juridique.
Dérapage des coûts et utilisation des jetons
Un risque qui surprend de nombreux décideurs n’est pas lié aux données, mais concerne entièrement l’aspect financier. Fisher décrit une situation plus courante qu’on ne le pense : « Disons que quelqu’un dirige accidentellement un agent codeur dans la mauvaise direction, ce qui entraîne la création d'une boucle qui tourne en permanence, générant continuellement des frais importants. Et, avant même de s’en rendre compte, un projet qui devait coûter 5 000 $ revient à 50 000 $ parce qu’ils ne savaient pas ce qui se passait en coulisse et supposaient que l’agent coder attraperait cela. »
Les créateurs non techniques sont également moins susceptibles d’optimiser l’utilisation des jetons de manière générale, ce qui signifie que les coûts peuvent s'accumuler discrètement et rapidement. Sans visibilité sur l’infrastructure sur laquelle leurs outils fonctionnent, vos collaborateurs peuvent ne pas se rendre compte du problème avant la réception de la facture.
Clés API et sécurité de l’information
C’est ici que Fisher aborde un sujet qui empêche les équipes de sécurité de dormir. Le scénario qu’il décrit est un modèle type de ce qui se passe lorsqu’on sait juste assez pour représenter un danger : « Une erreur courante est lorsque quelqu’un sait juste assez pour reconnaître et expliquer qu’il faut une clé API pour réaliser quelque chose. Il fournit la clé dans une invite, et elle n’est pas stockée en lieu sûr — elle est simplement placée dans un fichier ou directement intégrée au script. Ensuite, quelqu’un poste le code sur GitHub, oublie de le rendre privé, et maintenant, cette clé API peut être exploitée par toute personne prête à commettre un acte malveillant, comme générer une facture de 100 K $ en jetons.»
Il est facile de lire ce scénario et de penser qu’il nécessite une longue chaîne d’erreurs. Fisher nuance cette intuition : « On a l’impression qu’il s’agit d’une succession improbable d’événements, mais ce n’est pas le cas. C’est en réalité extrêmement fréquent, surtout pour les personnes non techniques. »
Peut-être que le risque le plus alarmant soulevé par Fisher est un piège dans lequel même les développeurs expérimentés peuvent tomber. « J’ai entendu des histoires d’horreur où des développeurs chevronnés déposent l’ensemble de la base de code d’une entreprise dans un agent codeur pour y apporter une modification, et l’ensemble du code se retrouve exposé à une autre entreprise, tout à fait dans les limites de la légalité. » Si même des développeurs expérimentés peuvent commettre cette erreur, le niveau de risque pour un collaborateur non technique qui construit vite et sans surveillance est bien plus élevé.
More Articles
- Comment 5 consultants en gestion de projet évaluent la préparation d’une équipe au changement lié à l’IA
- L’IA dans la gestion des risques de projet : applications clés, outils et cadre d’adoption étape par étape
- L’IA dans la gestion des risques : Guide exécutif des opportunités, défis et cas d’utilisation
Le problème de la montée en charge — Que se passe-t-il lorsque ça fonctionne vraiment ?
Une des conversations les plus délicates pour les décideurs porte sur la marche à suivre quand un outil « vibecodé » résout réellement un problème, et que les équipes commencent à en dépendre. Le succès peut silencieusement devenir un risque. Fisher souligne la question structurelle : « D’une manière générale, tous les projets codés avec cette approche ne sont pas scalables, essentiellement parce que vous ne demandez pas à l’agent de se préoccuper de la montée en charge. Les non-développeurs ne demandent probablement pas non plus de gestion des erreurs. Si vous ne comprenez pas où les erreurs peuvent se produire, vous n’avez pas assez de recul pour garantir que l’agent les détecte et les gère de manière appropriée. »
De manière générale, tous les projets codés au feeling ne sont pas évolutifs, principalement parce que vous ne demandez pas à l’agent de prendre en compte la mise à l’échelle.
L'écart de responsabilité devient le plus visible sous pression. « Ce qui a tendance à se produire, c'est que quelqu’un code un truc au feeling, puis ça fonctionne, mais est-ce que cette personne devient le support technique 24/7 pour ce produit ? » Pour les responsables de la livraison et des opérations, c’est à ce moment précis qu’un outil interne bien intentionné se transforme en risque organisationnel — car plus les équipes en dépendent, plus il est susceptible de tomber en panne ou de nécessiter un support technique constant.
La recommandation de Fisher pour les outils qui prennent de l’ampleur est une transmission claire : « Si vous construisez quelque chose dont d'autres dépendent, cela doit devenir plus qu’un projet codé au feeling ; il faut que ce soit absorbé par des professionnels qui connaissent des choses auxquelles vous ne penseriez même pas à demander. »
Que peuvent faire les dirigeants — Garde-fous pratiques
Cela ne veut pas dire qu’il faut tout interdire. Fisher est clair sur ce point — la valeur du code fait maison pour les personnes non techniques est réelle, mais elle se limite à un domaine précis. « L'intérêt de ces outils pour ceux qui ne codent pas, c’est de pouvoir raccourcir des étapes comme l’alignement autour d’une idée et de dépasser la phase du “est-ce que ça va marcher ?” », dit-il. La phase de prototypage, la phase de communication, la phase « vaut-il la peine d’être construit ? » — voilà où le code fait maison est pertinent et où le risque reste gérable.
Pour les dirigeants, la stratégie concrète ressemble à ceci : encouragez le codage maison comme outil de prototypage et de communication, puis fixez un seuil clair à partir duquel un expert technique revoit l’outil avant son usage élargi. Avoir ces discussions avec votre équipe — pour qu’elle comprenne les risques et connaisse ses options — c’est ce qui distingue une culture d’exploration intelligente de l’IA d’une organisation qui fonce tête baissée en misant sur la chance.
Le but n’est pas d’être le dirigeant qui dit non. Il s’agit d’être celui qui s’assure que l’équipe sait à quoi elle s’expose — afin que lorsqu’une personne construit quelque chose de remarquable, cela puisse vraiment aller loin.
Vous voulez encore plus d’analyses comme celles-ci ? Inscrivez-vous à un compte DPM gratuit pour recevoir d’autres conseils d’experts.