# 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.

> INFO : une « chaîne d'approvisionnement logicielle » compromise ne
nécessite pas que VOTRE code contienne une faille — il suffit qu'UNE de ses
dépendances (ou une dépendance de cette dépendance) en introduise une, via
une mise à jour que personne n'a individuellement relue. Plus la chaîne est
courte, moins il y a de maillons où cela peut se produire sans être
remarqué.

## 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.

> ASTUCE : ce principe se décide au cas par cas, pas comme un dogme absolu
— un projet à fort périmètre fonctionnel bénéficiera souvent davantage
d'une dépendance mature et largement auditée que d'une réimplémentation
maison hâtive. La question à se poser est plutôt : « cette dépendance
précise mérite-t-elle la confiance que je lui accorde, pour ce cas
d'usage précis ? », pas « toute dépendance est-elle mauvaise ? ».

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