Le « vibe coding » transforme le développement. Votre gouvernance suit-elle ?

Imaginez que vous croisiez quelqu'un au siège de votre entreprise et que vous découvriez qu'il s'agit d'un développeur junior freelance qui travaille ici depuis des mois. Vous n'en avez jamais entendu parler. Le PDG ne vous a jamais informé parce que vous étiez trop occupé.

Ce développeur, que vous n'avez jamais intégré, envoie tout son code directement en production au feeling.

Alors que beaucoup ont déjà adopté des outils comme Claude Code, deux scénarios de « vibe coding » reviennent sans cesse pour les administrateurs. D'un côté, il y a ceux qui ont accepté de donner à une IA un accès à l'architecture qu'ils ont soigneusement bâtie. De l'autre, il y a ceux qui ne savent même pas que les développeurs de leurs équipes utilisent des outils comme Claude Code, construisant avec comme s'il s'agissait d'un partenaire.

Dans cet article, nous explorerons comment le « vibe coding » modifie la façon dont les développeurs travaillent, ce que cela implique pour les administrateurs et les CTO, et comment protéger les postes de travail des développeurs face aux nouveaux risques qui en découlent.

Comprendre le « vibe coding » : pourquoi tant d'agitation ?

Le « vibe coding » consiste à demander à un outil d'IA de générer du code immédiatement exécutable. Des outils comme Claude Code, Gemini, DeepSeek ou Cursor permettent de créer des applications très rapidement, parfois avec très peu d'intervention manuelle.

En pratique, certains développeurs rédigent une spécification. Ce document explique ce qu’ils veulent construire, comment cela doit fonctionner et quelles règles doivent être respectées. L’IA génère ensuite le code à partir de cette description. D’autres rédigent des commentaires détaillés directement dans leur code, et l’IA complète la logique. Dans les deux cas, l’idée est la même : le développeur fournit suffisamment de contexte pour que l’IA puisse prendre des décisions au lieu de simplement supposer.

Par exemple, au lieu d’écrire manuellement un endpoint d’API REST, un développeur décrit le schéma, les règles d’authentification et le comportement attendu, et l’IA génère l’endpoint complet, tests inclus. En somme, les vibe codeurs délèguent à l’IA l’un des trois piliers de l’informatique : transformer un besoin métier en une application fiable et fonctionnelle.

Un gain de productivité qui a un prix

Grâce au « vibe coding » les développeurs peuvent créer plus rapidement, tester leurs idées sans attendre et consacrer moins de temps aux tâches répétitives. Cela s'avère également utile pour debugger ou pour trouver des réponses rapides. Le gain de productivité est alors significatif à court terme.  

Le code généré par l'IA peut sembler correct tout en présentant des problèmes. Il peut avoir une structure fragile, des performances médiocres ou de mauvaises pratiques qui ne sont pas toujours faciles à déceler. Si personne ne relit ses résultats, cela peut fragiliser les systèmes et conduire à un code difficile à maintenir. C'est à ce stade que les équipes peuvent commencer à dépendre d'outils qu'elles ne maîtrisent pas totalement.

À long terme, cette pratique transforme donc en profondeur la manière dont les équipes travaillent. Les développeurs écrivent peut-être moins de code, mais ils ne se sentent pas nécessairement moins sous pression. Ils passent en réalité davantage de temps à vérifier, corriger et tenter de comprendre ce que l’IA a généré.

En effet, il est plus difficile de relire du code que l’on n’a pas écrit soi-même. Il faut davantage de concentration pour tenter de comprendre. Et comme l’IA n’est pas toujours prévisible, cela peut susciter de la frustration voire du stress.  

Pourquoi la relecture du code reste essentielle

Dans le développement, l’IA peut par exemple inventer des fonctions, créer une logique erronée ou passer à côté de problèmes de sécurité importants. Le deuxième problème est plus grave. Les systèmes d’IA peuvent être manipulés par le biais de ce qu’on appelle l’« injection de prompt ».

Lorsque les outils d’IA récupèrent des données externes, ils peuvent être influencés par des instructions cachées intégrées dans ce contenu. Des chercheurs en sécurité ont démontré que Claude pouvait être dupé par les sources malveillantes lorsqu’ils recherchent des informations en ligne. Un hacker peut ainsi créer une page web malveillante contenant des instructions cachées. L’IA en lisant cette page, exécute ces instructions comme s’il s’agissait d’une entrée légitime, sans détecter la menace.  

Du point de vue de l’utilisateur, rien ne semble anormal : l’IA fait simplement son travail. Mais en réalité, cela peut avoir de graves conséquences. Si l’agent IA fonctionne avec des droits d’accès élevés au système, un hacker pourrait alors accéder à des données sensibles, voler des identifiants ou installer des logiciels malveillants sur le PC.  

La confiance n’exclut pas le contrôle

Ce crédo qui circule des écoles de cuisine aux rangs de soldats en formation, devrait trouver sa place parmi les adeptes du vibe coding. Dans le cas du développeur, contrôler c’est avant tout remettre systématiquement en question les résultats de l’IA, en demandant des sources, en vérifiant les faits, et en s’assurant que les conclusions s’appuient sur des preuves tangibles.  

Que fait réellement ce morceau de code ? Quelles preuves montrent que le problème provient d’une partie spécifique de l’infrastructure ? C’est ce type de réflexion qui permet à l’IA de révéler tout son potentiel.

L’IA peut aider, mais elle ne peut pas remplacer la responsabilité. C’est pourquoi les revues de code, les tests et les contrôles de sécurité doivent toujours faire partie du processus.

Malgré ses limites, le plus grand risque ne vient pas de la technologie en elle-même : elle vient de la façon dont les gens l’utilisent. Il peut sembler tentant de sauter l’étape de la vérification du code pour gagner du temps. Or, cette étape devient d’autant plus cruciale à l’heure du développement assisté par IA.

Sécuriser le développement assisté par IA

Au-delà des pratiques des développeurs, le CTO a aussi un rôle à jouer. Ses choix architecturaux et technologiques doivent permettre de fournir aux développeurs un environnement adapté à leurs besoins. Ceux-ci devraient disposer d’un espace dédié, adapté à leur activité.

En général, un développeur se voit octroyer un poste d’entreprise standard dont les politiques de sécurité standards freinent sa productivité. Résultat : des requêtes à n’en plus finir auprès de l’administrateur pour obtenir une élévation de ses droits. Parfois, ce dernier finit par céder. Le développeur est ravi, l’admin ne dort plus la nuit. Quant au RSSI...

Quand l’inverse se produit, le développeur n’obtient pas gain de cause, il cherchera, comme tout utilisateur censé, une alternative pour parvenir à son but. Pour le meilleur et pour le pire. L’admin et le RSSI ne le découvriront que trop tard, lorsqu’un poste dev sera compromis.

A cela s’ajoute le nombre de postes de travail qu’il doit utiliser. Si pour des raisons de sécurité, l'environnement de développement et celui de l’entreprise sont séparés, dans la pratique opérationnelle cela se traduit par un ballet ininterrompu entre deux postes de travail : deux SI, deux écrans, double peine.

Pourtant de nouvelles approches pourraient permettre aux développeurs d’avoir, enfin, un environnement de travail adapté à leurs besoins réels.  

Moins de PC, plus d'environnements : le poste de travail multi-environnements

Une première étape pratique consiste à créer des environnements distincts pour l'utilisation de l'IA. Au lieu de s'exécuter directement dans l'espace utilisateur principal, Claude Code peut être placé dans son propre profil système. De cette manière, l'accès aux fichiers et aux applications est limité par conception, plutôt que laissé au hasard.

Cela ouvre également la voie à une réflexion plus large sur l'architecture des postes de travail. Les configurations multi-environnements, recommandées par l'ANSSI, offrent un cadre solide. Un espace peut être utilisé pour le travail quotidien, un autre pour les données hautement sensibles, et un troisième pour les tâches assistées par IA. Organiser les flux de travail à travers ces frontières permet de contrôler ce à quoi l'IA peut accéder et ce qu'elle peut influencer à tout moment. Exécuter les outils d'IA au sein d'une machine virtuelle, idéalement supportée par un hyperviseur de type 1, ajoute une couche de séparation supplémentaire entre le système contenant des données sensibles et celui qui interagit avec l'IA. Cela ne supprime pas le risque, mais réduit une exposition étendue à un périmètre plus contenu.

Dans cette configuration, Claude Desktop fonctionne dans un environnement contrôlé, tandis que les informations critiques restent hors de portée directe. Même en cas de problème, l'impact demeure limité à un périmètre défini.

‍Conclusion : Protégez les postes de travail de vos développeurs, protégez votre architecture‍

Fournir à vos développeurs un environnement dédié est la première étape pour protéger l'architecture que vous avez méticuleusement construite, au cas où leurs postes de travail seraient piratés ou contaminés. La véritable compétence réside dans le jugement humain : savoir ce qui doit être vérifié, détecter les détails manquants et reconnaître les limites de compréhension du modèle. L'IA opère sans connaissance complète de son environnement d'exécution, en particulier concernant les contraintes internes telles que l'architecture réseau, les politiques de sécurité et les exigences opérationnelles. Naviguer dans ces angles morts est ce qui distingue une utilisation efficace de l'IA d'une dépendance risquée. Nos développeurs internes travaillent avec la solution même que nous avons conçue. Une solution qui offre aux développeurs un environnement répondant enfin à leurs besoins d'autonomie tout en permettant la visibilité de l'administrateur.

Prêt à reprendre la main ?

‍