# 4. Principe : la souveraineté du code

La **souveraineté du code** est le deuxième pilier de sécurité de ce guide,
complémentaire du premier (limiter la surface d'action de l'agent). Elle
répond à une question différente : une fois le code écrit, **de qui
dépend-il pour fonctionner ?**

## Ce que veut dire « souverain » ici

- **Bibliothèque standard uniquement** : le code n'utilise que ce que le
  langage fournit nativement, sans bibliothèque tierce.
- **Zéro dépendance externe** : rien à installer, rien à mettre à jour pour
  suivre une vulnérabilité découverte chez un tiers, rien qui puisse changer
  de comportement à l'insu de l'auteur (une mise à jour de dépendance
  compromise est un vecteur d'attaque réel et documenté, dit de « chaîne
  d'approvisionnement »).
- **Zéro appel réseau non maîtrisé** : le code ne contacte que ce qu'on lui
  demande explicitement de contacter, jamais un service tiers en arrière-plan.

## Pourquoi ce principe réduit le risque, indépendamment de la question de l'agent

Même un outil qui n'a **aucune** interaction avec un agent IA bénéficie de ce
principe : moins de code tiers exécuté, c'est moins de surface pour un bug
ou une compromission découverts après coup, chez un mainteneur qu'on ne
contrôle pas. C'est un principe de sécurité générale, pas seulement une
réponse à l'injection de prompt.

## Le compromis assumé

Réécrire soi-même ce qu'une bibliothèque ferait en quelques lignes coûte du
temps de développement, et impose parfois des limites fonctionnelles
assumées (documentées honnêtement plutôt que cachées) par rapport à une
solution industrielle complète. Ce guide et les outils qui l'accompagnent
font ce choix délibérément pour un périmètre de tâches précis et restreint —
ce n'est pas une recommandation universelle valable pour tout projet.

*(Schéma disponible : `schema.svg`, dans ce dossier.)*