Assistants de code IA en Suède : clés d'API, secrets et code source

La Suède a l'une des scènes tech les plus actives d'Europe. Dans les start-up de Stockholm, Göteborg ou Malmö, les assistants de code font déjà partie du quotidien : complétion dans l'éditeur, agents en ligne de commande, assistants qui lisent tout un dépôt pour proposer une correction.

Ces outils font gagner un temps réel. Mais ils voient tout ce que le développeur voit : fichiers de configuration, clés d'API, extraits de base de données, code propriétaire. Pour une entreprise tech suédoise, la question n'est plus de savoir s'il faut les utiliser, mais comment éviter qu'ils emportent des secrets avec eux.

Ce que voit vraiment un assistant de code

Un assistant classique reçoit le fichier ouvert et un peu de contexte. Un agent moderne va beaucoup plus loin : il parcourt l'arborescence, lit les fichiers qu'il juge utiles, lance des commandes et lit leur sortie. Tout ce qui passe par là peut être envoyé au modèle.

Dans un dépôt réel, cela inclut souvent :

• des fichiers .env avec des clés d'API, des mots de passe de base de données ou des jetons de service ;

• des fichiers de configuration cloud et des identifiants laissés en clair ;

• des journaux d'erreurs qui contiennent des adresses e-mail, des numéros de clients ou des personnummer ;

• le code source lui-même, souvent le principal actif de l'entreprise.

Nous avons détaillé ces scénarios dans notre article sur les fuites de secrets par les agents CLI.

Les secrets d'abord : clés d'API et jetons

Une clé d'API envoyée à un service externe doit être considérée comme compromise. Même si le fournisseur ne la réutilise pas, elle se retrouve dans des journaux, des historiques de conversation ou des sessions partagées. La seule réponse sûre est alors de la révoquer et de la remplacer, ce qui coûte du temps et peut casser la production.

Le plus efficace reste d'empêcher la clé de partir. Cela suppose de la reconnaître au moment où elle est collée dans un prompt ou lue par un agent, et pas seulement lors d'un scan du dépôt après coup.

Les hooks de pré-commit et l'analyse des dépôts en intégration continue restent utiles. Mais ils interviennent quand le code est enregistré, pas quand un développeur colle une configuration dans une fenêtre de chat pour comprendre une erreur.

Le code source, un secret d'affaires

En Suède, la loi sur les secrets d'affaires, lagen (2018:558) om företagshemligheter, transpose la directive européenne de 2016. Une information n'est protégée que si son détenteur a pris des mesures raisonnables pour la garder secrète.

Pour une entreprise de logiciels, l'algorithme de tarification, le moteur de recommandation ou le code de détection de fraude sont exactement ce type d'information. Laisser ce code circuler sans contrôle vers des outils externes affaiblit l'argument, le jour où il faudra prouver qu'on le protégeait vraiment.

Données personnelles : l'IMY reste compétente

Les développeurs manipulent aussi des données personnelles, souvent sans y penser : un export de base pour reproduire un bug, un journal qui contient des noms et des personnummer. Si ces données partent vers un assistant d'IA, le RGPD s'applique, et l'autorité suédoise de protection des données, l'Integritetsskyddsmyndigheten (IMY), est compétente.

Pour les entreprises qui relèvent de la nouvelle loi suédoise sur la cybersécurité (cybersäkerhetslagen), qui transpose NIS2, la maîtrise de ces flux fait aussi partie de la gestion des risques. Côté secteur public, notre premier article sur le pays traite des communes suédoises, de l'IMY et du secret.

MCP et agents : une nouvelle surface

Le Model Context Protocol (MCP) permet aux agents de se connecter directement à des bases de données, des outils de tickets ou des dépôts. C'est pratique, mais chaque connecteur ouvre un nouveau chemin par lequel des données sensibles peuvent atteindre le modèle, sans que le développeur les ait collées lui-même.

Ces flux échappent souvent aux outils de sécurité classiques. Nous expliquons pourquoi dans notre article sur la nécessité d'une couche DLP dédiée pour MCP.

Une politique simple pour les équipes de développement

Interdire les assistants de code n'est ni réaliste ni souhaitable. Une politique efficace tient en quelques règles claires :

1. Lister les outils autorisés, avec des contrats qui excluent l'entraînement sur vos données.

2. Sortir les secrets du code : gestionnaire de secrets, pas de clés dans les fichiers versionnés.

3. Utiliser des données de test plutôt que des extraits de production pour le débogage.

4. Contrôler au moment de l'envoi ce qui part vers les modèles, y compris via les agents.

5. Garder une trace des incidents, pour corriger les pratiques et répondre aux audits.

Comment ZeusLock protège les équipes tech

ZeusLock fonctionne sur les postes des développeurs et dans leurs navigateurs. Il reconnaît les clés d'API, les jetons, les mots de passe, les données personnelles comme les personnummer et les fragments de code que vous marquez comme sensibles. Selon la règle, il avertit, bloque ou remplace la valeur par une valeur fictive de même format, pour que l'assistant puisse continuer à aider.

Chaque événement est journalisé. L'équipe sécurité voit quels outils sont utilisés et quels types de données ont été interceptés, sans lire tout le code des développeurs.

Pour les développeurs, tout se joue sur la friction. Un outil qui bloque tout finit contourné. Avec une valeur fictive plausible à la place de la clé, l'assistant comprend toujours la structure du fichier et propose une correction utile.

En résumé

Les assistants de code sont devenus des outils de travail normaux dans la tech suédoise. Ils voient pourtant des clés, du code propriétaire et des données personnelles. Avec des règles claires et un contrôle au moment de l'envoi, on garde la vitesse sans perdre ses secrets.

Vous voulez voir comment ZeusLock protège vos clés d'API et votre code dans les assistants d'IA ? Demandez une démo.