Ne faites pas confiance aux bonnes intentions de votre copilote IA

Ne faites pas confiance aux bonnes intentions de votre copilote IA

Voilà la chose : votre assistant de programmation IA n’est pas malveillant. Mais il ne sait pas ce qui est dangereux. Et c’est un problème.

Simon Willison a baptisé ce phénomène **« la triste trinité »** : des données privées, du contenu non fiable, et un moyen de les exfiltrer — le tout en une seule session. C’est exactement ce qui se passe quand on laisse une IA agent libre sur votre code, vos fichiers locaux, ou même vos onglets de navigateur. Elle lit tout, fait des liens, et ensuite… envoie des choses vers des API. Peut-être pas intentionnellement. Mais ça arrivera.

Alors arrêtez de compter uniquement sur les filtres de type prompt.

Laisse-moi vous expliquer pourquoi.

---

C’est quoi les filtres de prompt ?

Les filtres de prompt sont des mécanismes de sécurité intégrés directement dans les instructions données à l’IA — souvent des consignes lui disant de ne pas faire certaines choses. Par exemple :

> « Ne mentionne jamais de chemins de fichiers. »
> « N’envoie jamais de données en dehors du système. »

Ces règles ont l’air parfaites en théorie. En pratique ? Elles se cassent facilement avec un excès de contexte, un tour de phrase malin, ou simplement parce que la machine oublie après un moment trop long.

C’est comme coller un post-it sur votre frigo qui dit « Ne mange pas le gâteau »… tout en laissant la porte grande ouverte.

---

Pourquoi le chemin d’exécution compte plus que les prompts

La vraie sécurité doit se faire là où les décisions sont prises : **dans le chemin d’exécution**. Cela signifie contrôler les actions pendant qu’elles arrivent — pas espérer que l’IA respectera des règles.

C’est un peu comme les lois de la route. Les panneaux aident à guider les comportements… mais les feux rouges, les ralentisseurs et les portails verrouillés empêchent physiquement les mauvaises actions. C’est exactement ce dont nous avons besoin pour l’IA.

Exemple 1 : Accès aux fichiers locaux qui tourne au désastre

Imaginez que vous créiez une application Flutter avec l’aide d’une IA. Vous lui demandez de refactoriser certains composants d’interface. Pendant la discussion, elle accède à la structure de votre projet — y compris des fichiers de configuration contenant des clés API.

Plus tard, au milieu de la conversation, vous lui demandez innocemment : « Tu peux résumer ce journal d’erreurs ? » Soudain, sans vous en rendre compte, l’IA intègre des morceaux de ces fichiers sensibles dans sa réponse.

Pourquoi ? Parce que rien n’a été mis en place pour l’empêcher.

À la place, imposez des limites via des outils de type sandbox ou des contrôles au niveau de l’environnement. Bloquez l’accès aux fichiers sensibles sauf si c’est expressément autorisé. Des outils comme [OpenCode](https://opencode.ai/) ou des agents personnalisés créés avec des frameworks comme LangChain peuvent acheminer les requêtes à travers des exécuteurs contrôlés au lieu d’un accès direct au shell.

Exemple 2 : Un bug dans une extension de navigateur

Vous utilisez une extension de navigateur assistée par IA pour rédiger des emails ou résumer des articles. Un jour, connecté à votre espace bancaire en ligne, vous activez l’IA pour « résumer cette page ». Et là… patatra ! Elle récupère aussi les numéros de compte et l’historique des transactions.

Même si le prompt contient « Ne partage pas d’informations personnelles », l’IA risque quand même de le faire. Il y a simplement trop de données visibles.

La solution ? Restreindre les autorisations d’analyse du DOM. Autorisez uniquement l’accès à certains domaines spécifiques. Utilisez l’isolation par iframe ou des navigateurs headless restreints aux sites autorisés.

Exemple 3 : Les risques liés aux interpréteurs de code

Des outils comme les notebooks Jupyter intégrant des LLM semblent sûrs — ils s’exécutent dans des conteneurs. Mais parfois, ils sont mal configurés. L’IA lit alors les variables système, récupère des clés SSH… pire : elle commence à envoyer des journaux vers des serveurs externes.

Il faut appliquer des politiques strictes sur les appels réseau, la visibilité des variables d’environnement et les écritures sur le disque — directement dans l’interpréteur lui-même. Pas seulement dans le prompt.

---

Comment construire des flux de travail IA plus sûrs ?

Alors, comment sortir du simple fait accru de confiance envers les prompts ?

Étape 1 : Définir les limites dès le départ
Fixez des frontières claires avant de laisser l’IA manipuler quoi que ce soit de sensible. Limitez les types de fichiers, les dossiers et les processus auxquels elle peut accéder.

Utilisez des outils comme :
- [GitHub Copilot Enterprise](https://github.com/features/copilot)
- [Replit Ghost](https://replit.com/site/ghost)
- Des exécuteurs d’agents personnalisés basés sur [LangGraph](https://www.langchain.com/langgraph)

Étape 2 : Surveiller les actions réelles
Enregistrez chaque appel API, lecture/écriture de fichier, commande shell et requête web effectuée par l’IA. Réexaminez-les régulièrement.

Si vous utilisez [Astra](https://arcprize.org/blog/astra) ou d’autres plateformes similaires, consultez leurs tableaux de bord télémétriques.

Étape 3 : Superposer les contrôles de sécurité
Ajoutez des pare-feux, des proxys et des coffres-forts pour les identifiants entre l’IA et les systèmes critiques. Ne stockez jamais les secrets en clair.

Des outils comme HashiCorp Vault ou AWS Secrets Manager s’intègrent facilement dans la plupart des pipelines de développement.

---

Réflexion finale : Faites attention à ce enquiqu’rez… euh, faire confiance

Les copilotes IA sont des alliés puissants — à condition de les contrôler correctement.

Compter uniquement sur des restrictions basées sur les prompts, c’est comme laisser votre porte d’entrée ouverte parce que vous espérez que les voleurs ne viendront pas. Ça échoue plus souvent que vous ne le pensez.

Créez des barrières dans votre infrastructure — pas seulement dans vos instructions.

Parce que la prochaine fois que votre IA décidera d’aider en partageant un fichier de configuration, vous ne voudrez pas découvrir ça après coup.

---

FAQ

Q1 : Est-ce que je peux juste désactiver l’accès à Internet ?
Oui, mais ça limite la fonctionnalité. Une meilleure idée : contrôler quelles URL ou quels points finaux l’IA peut atteindre.

Q2 : Est-ce que ça existe déjà dans la plupart des plateformes ?
Pas complètement. Beaucoup offrent des protections de base, mais elles reposent souvent sur les prompts plutôt que sur des restrictions au niveau de l’exécution.

Q3 : Et les environnements sandbox ?
Absolument. Les conteneurs, les machines virtuelles et les shells restreints font une grande différence pour éviter les fuites accidentnelles.

Q4 : Où puis-je en apprendre davantage sur la sécurité de l’IA ?
Jetez un œil au blog de Simon Willison ([simonwillison.net](https://simonwillison.net/)) et suivez les actualités des équipes sécurité d’organisations comme Mozilla ou celle d’OpenAI.