Séparer les comptes Unix pour sécuriser les agents de programmation IA

Donner à un agent de programmation IA votre propre compte Unix est un raccourci dont les conséquences peuvent durer longtemps. L’agent hérite de fichiers dont vous aviez oublié l’existence, d’identifiants mis en cache par des outils depuis des années, d’une configuration SSH trop permissive, de scripts de déploiement et de la capacité à faire passer une mauvaise modification pour un travail ordinaire. Un compte distant dédié ne rend pas un agent inoffensif, mais il rend son autorité visible et plus facile à contenir.

Considérez ce compte comme une limite autour d’une tâche précise. Si l’agent doit modifier un dépôt, exécuter sa suite de tests et pousser une branche, créez une identité capable de faire exactement cela. Ne commencez pas avec votre compte de développeur en essayant de retirer les privilèges plus tard. Les permissions Unix s’accumulent par l’intermédiaire des groupes, des répertoires montés, de la configuration du shell et d’outils qui supposent qu’un humain garde le contrôle.

Un compte Unix distinct donne à l’agent une autre identité

Un compte dédié donne à l’agent un UID, un propriétaire de processus, un répertoire personnel, un ensemble d’autorisations SSH et une trace d’audit distincts. Ces cinq éléments comptent davantage qu’une invite ingénieuse demandant à l’agent de rester dans un dépôt.

Quand un agent s’exécute sous alex, tous les processus qu’il lance appartiennent à alex. Ces processus peuvent lire tout ce que alex peut lire. Ils peuvent utiliser l’agent SSH de alex si la redirection ou des sockets le rendent accessible. Ils peuvent examiner l’historique du shell, les identifiants Git, la configuration cloud, les caches du gestionnaire de paquets et les répertoires de projet appartenant à alex ou lisibles par lui. Même si l’agent se comporte parfaitement aujourd’hui, ses permissions futures dépendent alors de chaque commodité que vous ajouterez à votre propre compte.

Un compte comme agentbuild rend le point de départ vérifiable :

id agentbuild
getent passwd agentbuild
sudo -u agentbuild sh -lc 'umask; pwd; env | sort'

Sur un hôte Linux classique, la première commande doit afficher un UID et une liste réduite de groupes. La deuxième doit indiquer un répertoire personnel comme /srv/agentbuild ou /home/agentbuild, et non celui d’un développeur. La dernière commande permet de repérer un problème souvent oublié : des variables d’environnement héritées peuvent pointer vers des fichiers d’identifiants, des proxys, des caches de jetons ou des chemins d’exécutables inhabituels.

Une distinction est souvent brouillée : une clé SSH distincte n’est pas un compte distinct. Une nouvelle clé qui ouvre une session sur votre compte existant ne change que l’authentification. Elle ne réduit en rien les fichiers, les commandes ou la configuration réseau disponibles après la connexion. L’authentification et l’autorisation répondent à deux problèmes différents.

Utilisez un compte stable pour une fonction stable. Si un agent construit des pull requests et qu’un autre déploie des artefacts de version, donnez-leur des identités différentes. Vous pourrez alors répondre sans deviner à une question opérationnelle délicate : quel compte a modifié ce fichier, ouvert cette connexion réseau ou créé ce processus ?

La limite du compte ne contient pas tous les types de dommages

Un compte Unix limite les accès contrôlés par le propriétaire des fichiers, les groupes, les listes de contrôle d’accès et les permissions Unix. Il ne limite pas automatiquement les destinations réseau, l’utilisation du processeur, la saturation du disque, les vulnérabilités du noyau, l’accès aux fichiers lisibles par tous ni les droits accordés par un identifiant de service partagé.

Cette limite reste très utile. Un agent de programmation peut souvent modifier le code source, exécuter des scripts de paquets, lire la configuration et utiliser Git. Les scripts de paquets peuvent exécuter des commandes shell arbitraires. Les systèmes de compilation peuvent lire les variables d’environnement. Une dépendance compromise peut faire la même chose. Partez du principe que tout code que l’agent demande à l’hôte d’exécuter reçoit les permissions du compte qui l’exécute.

Ne confondez pas la séparation des comptes avec un conteneur, une machine virtuelle ou un pare-feu réseau. Ces mécanismes ont des rôles différents :

• Un compte Unix sépare les fichiers locaux, la propriété des processus et les permissions ordinaires des commandes.
• Un conteneur peut limiter la vue du système de fichiers et l’utilisation des ressources, mais un répertoire hôte mal monté annule cet avantage.
• Une machine virtuelle fournit une limite plus forte au niveau du système d’exploitation lorsque la charge de travail le justifie.
• Les contrôles réseau déterminent vers quelles destinations le compte peut se connecter et quelles données peuvent quitter l’hôte.

Choisissez la combinaison la plus réduite correspondant aux conséquences d’une défaillance. Pour un dépôt de test jetable, un compte dédié sur un worker isolé peut suffire. Pour un hôte de déploiement en production, associez la limite du compte à un SSH restreint, des identifiants de déploiement précis, des journaux et une politique de sortie réseau. Si l’agent peut atteindre des bases de données de production ou du matériel de signature, un UID distinct est manifestement insuffisant.

Une recommandation populaire mais incorrecte consiste à créer un compte et à l’ajouter aux mêmes groupes opérationnels que le développeur « pour que les compilations fonctionnent ». Cela recrée le problème initial sous un autre nom d’utilisateur. Des groupes comme docker, libvirt, les groupes de sauvegarde, de périphériques et de journaux privilégiés peuvent conférer une autorité très supérieure à ce que leur nom laisse penser. Sur de nombreux systèmes, appartenir à docker permet de contrôler l’hôte, car un membre peut lancer un conteneur avec le système de fichiers hôte monté.

Créez un compte sans héritage accidentel

Créez le compte distant sans connexion par mot de passe, sans groupe d’administration et avec un répertoire personnel ne contenant que les fichiers que vous y placez volontairement. Commencez avec un répertoire vide : les fichiers de configuration copiés sont une source fréquente d’autorité accidentelle.

Les commandes exactes dépendent du système d’exploitation. Sur un hôte de type Debian ou Ubuntu, un administrateur peut créer un compte local avec un répertoire personnel dédié ainsi :

sudo adduser --disabled-password --gecos '' --home /srv/agentbuild agentbuild
sudo passwd -l agentbuild
sudo install -d -m 700 -o agentbuild -g agentbuild /srv/agentbuild/.ssh
sudo -u agentbuild touch /srv/agentbuild/.hushlogin

--disabled-password empêche l’authentification normale par mot de passe pour le nouveau compte. passwd -l rend cette intention explicite sur les systèmes qui prennent en charge le verrouillage des mots de passe. Ne considérez aucun de ces réglages comme votre seul contrôle SSH : le serveur SSH possède ses propres paramètres d’authentification par mot de passe, et une clé déjà installée peut toujours permettre l’authentification.

Sur les systèmes qui utilisent useradd, choisissez les options qui créent le répertoire personnel et un groupe privé, puis vérifiez le résultat au lieu de vous fier à vos souvenirs. La gestion des comptes BSD et macOS utilise d’autres outils. Consultez donc la documentation locale de dscl, sysadminctl ou de l’administration système plutôt que de coller des commandes Linux sur un autre hôte.

Vérifiez immédiatement les propriétaires :

namei -l /srv/agentbuild/.ssh
sudo -u agentbuild sh -lc 'touch ~/permission-test && ls -ln ~/permission-test'
sudo rm /srv/agentbuild/permission-test

La sortie de namei parcourt chaque composant du chemin. Aucun répertoire parent ne doit accorder à un groupe sans rapport un accès en écriture, car cela pourrait permettre de remplacer le répertoire .ssh ou de manipuler les fichiers qu’il contient. Le fichier de test doit afficher l’UID numérique et le GID principal du compte.

Ne copiez pas votre .bashrc, .zshrc, .gitconfig ou votre répertoire d’éditeur dans ce répertoire personnel « pour gagner du temps ». Ces fichiers ajoutent souvent des registres de paquets privés, des alias, des réglages SSH, des gestionnaires d’identifiants et des hooks de shell. Ajoutez les réglages un par un, après avoir établi pourquoi l’agent en a besoin. Un shell simple et non interactif devrait de toute façon être la configuration par défaut pour l’automatisation distante.

Définissez un masque de création prudent dans l’environnement d’exécution de l’agent. Une umask de 077 rend les nouveaux fichiers ordinaires privés pour le compte, sauf si une commande choisit explicitement d’autres permissions. Cela révélera parfois une hypothèse de compilation. C’est une bonne chose. Corrigez précisément le point de partage de la compilation au lieu de rendre chaque fichier généré lisible par tous les utilisateurs locaux.

Les dépôts partagés ont besoin d’une règle de propriété conçue à l’avance

L’agent devrait travailler dans un dépôt dont il est propriétaire, ou dans un répertoire de projet dont vous pouvez expliquer les groupes et les permissions. Un répertoire dans lequel développeurs, outils de déploiement et agents écrivent comme des utilisateurs indépendants devient impossible à comprendre après la première correction précipitée des permissions.

Le modèle le plus propre consiste à faire appartenir entièrement le dépôt au compte de l’agent. Un humain examine les modifications avec le contrôle de version ou lit les fichiers grâce à un accès de groupe maîtrisé. Cela supprime la plupart des confusions liées à la collaboration locale, et Git fournit le mécanisme de transmission qui compte vraiment.

Parfois, l’agent doit écrire dans une arborescence de compilation commune. Dans ce cas, créez un groupe de projet dédié et activez le bit setgid sur le répertoire partagé afin que les nouveaux fichiers héritent du groupe :

sudo groupadd projectbuild
sudo usermod -aG projectbuild agentbuild
sudo install -d -m 2770 -o releasebot -g projectbuild /srv/project-build
sudo setfacl -m u:agentbuild:rwx /srv/project-build
sudo setfacl -d -m g:projectbuild:rwx /srv/project-build

Cet exemple doit être adapté à votre modèle de propriété. L’objectif n’est pas de suivre une mode avec les listes de contrôle d’accès. Il est de désigner clairement la surface de collaboration et de limiter l’écriture à cette surface. Ne répondez pas à une erreur de permission avec chmod -R 777 ou en plaçant toute une arborescence source dans un groupe d’administrateurs partagé. Ces deux solutions masquent le problème jusqu’à ce que quelqu’un écrive là où il ne devrait pas.

Un problème subtil apparaît lorsqu’un répertoire de compilation contient des liens symboliques. L’agent peut avoir l’autorisation d’écrire dans /srv/project-build, alors qu’un lien situé à l’intérieur pointe vers /etc, un répertoire de versions ou le répertoire personnel d’un humain. Examinez les scripts d’installation et les répertoires générés avant d’accorder un accès récursif étendu. La limite du compte ne protège que les chemins réellement évalués avec les permissions de ce compte.

Git possède un contrôle de propriété lié. Les versions modernes peuvent refuser un dépôt qui semble appartenir à un autre utilisateur en invoquant une « propriété douteuse ». Ne résolvez pas ce problème en ajoutant des répertoires arbitraires aux réglages globaux safe.directory de l’agent. Faites appartenir le dépôt au compte qui exécute Git. Si un dépôt partagé est inévitable, documentez sa propriété et n’ajoutez ce chemin précis qu’après avoir compris pourquoi Git l’a refusé.

L’accès SSH doit identifier le contrôleur et limiter la session

Utilisez une clé publique SSH dédiée pour le contrôleur de l’agent, puis associez des restrictions à cette clé dans authorized_keys lorsque le flux de travail le permet. Un compte distinct avec un shell interactif sans restriction vaut mieux que le partage d’un compte de développeur, mais il donne encore à un processus autonome une vaste surface de commandes.

OpenSSH documente les contrôles disponibles dans sshd_config(5) et authorized_keys. PasswordAuthentication no désactive les connexions par mot de passe au niveau du serveur. AllowUsers peut limiter les utilisateurs autorisés à se connecter. Les options par clé peuvent désactiver la redirection de ports, la redirection de l’agent, la redirection X11 et l’allocation d’un pseudo-terminal. Ces options sont des contrôles courants, pas une configuration SSH exotique.

Pour un agent qui doit seulement recevoir une commande Git ou exécuter un wrapper fixe, une entrée authorized_keys peut ressembler à ceci :

restrict,command="/usr/local/libexec/agent-git-wrapper" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... agent-controller

L’option restrict d’OpenSSH est une abréviation qui désactive plusieurs fonctions de redirection et de session, selon la version du serveur et la page de manuel. La commande forcée signifie que le serveur exécute le wrapper au lieu d’accepter la commande demandée par le client. Testez votre version d’OpenSSH avant de compter sur une option, car les anciens hôtes ne prennent pas forcément toutes les restrictions en charge.

Le wrapper doit valider ses propres entrées. Une commande forcée ne transforme pas un script négligent en limite de sécurité. S’il transmet à sh -c une commande fournie par le client sans la protéger correctement, celui-ci peut souvent retrouver la possibilité d’exécuter des commandes. Gardez le wrapper court, utilisez des chemins fixes, refusez les arguments inattendus et journalisez la demande.

Pour un agent de programmation généraliste qui doit explorer, modifier, compiler et tester, les commandes forcées peuvent être trop restrictives. Conservez la clé et le compte dédiés, désactivez les redirections inutiles et limitez les adresses sources lorsque la topologie réseau le permet. Le compte distant ne doit jamais accepter votre clé SSH personnelle simplement parce qu’elle se trouve déjà sur votre ordinateur portable.

Examinez la configuration SSH effective, pas seulement le fichier que vous avez modifié :

sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin|allowusers|allowgroups'
ssh -vvv agentbuild@build-host true

La première commande affiche les réglages effectifs du serveur. La deuxième montre, côté client, le chemin d’authentification et les méthodes refusées. Testez avec la clé réelle de l’agent. Un test effectué avec votre propre clé ne prouve presque rien.

Les règles sudo annulent souvent la protection que vous venez d’ajouter

N’accordez pas de sudo sans restriction à un compte d’agent. agentbuild ALL=(ALL) NOPASSWD: ALL rend l’UID distinct presque décoratif, car toute commande ou tout script exécuté par l’agent peut alors devenir root.

Cette règle est souvent ajoutée lorsqu’une compilation a besoin d’une seule action privilégiée, puis conservée parce que la compilation a enfin réussi. C’est ainsi qu’une exception étroite devient un contrôle permanent de l’hôte. Si une tâche a réellement besoin d’une élévation, demandez d’abord si un service appartenant à root, un worker de déploiement ou une action distincte d’un administrateur ne devrait pas s’en charger.

Le manuel sudoers(5) rappelle que la correspondance des commandes a ses limites. Les arguments comptent. Les jokers peuvent correspondre à davantage de cas que prévu. Autoriser un éditeur, un interpréteur, un gestionnaire de paquets, un script shell modifiable par l’agent ou une commande qui charge sa configuration depuis un répertoire accessible en écriture peut ramener directement à l’exécution arbitraire en tant que root.

Un modèle plus sûr utilise un wrapper appartenant à root et dont le comportement est fixe. Supposons qu’un agent doive redémarrer un seul service connu après avoir placé un artefact déjà vérifié dans un répertoire déterminé. Le wrapper doit utiliser des chemins absolus, refuser les arguments, vérifier la propriété et les permissions de ses entrées, puis effectuer uniquement ce redémarrage. La règle sudo doit alors nommer exactement ce wrapper :

Cmnd_Alias AGENT_RELEASE = /usr/local/sbin/restart-project-service
agentbuild ALL=(root) NOPASSWD: AGENT_RELEASE

Placez la règle dans un fichier géré avec visudo, et faites en sorte que le wrapper comme son répertoire parent appartiennent à root et ne soient pas accessibles en écriture par agentbuild. Cela ne garantit pas la sécurité, mais rend l’affirmation étroite vérifiable : le compte peut exécuter un seul programme appartenant à root, sans chaîne de commande contrôlée par l’appelant.

Si vous ne pouvez pas décrire l’action privilégiée autorisée en une phrase, n’accordez pas encore sudo. Découpez le travail jusqu’à pouvoir le faire. La difficulté est un signal de conception, pas une raison de coller une règle trop large.

Les identifiants ont besoin d’une limite distincte de celle du compte de connexion

Même un compte restreint devient dangereux si son répertoire personnel contient un fichier d’identifiants cloud, un jeton de déploiement trop large ou une clé privée SSH qui donne accès à tous les hôtes. Ne déplacez pas votre collection d’identifiants de votre répertoire personnel vers celui de l’agent en considérant la tâche terminée.

Émettez des identifiants adaptés à l’action, à la portée et à l’environnement dont l’agent a réellement besoin. Un identifiant de contrôle de source pouvant pousser vers un seul dépôt est différent d’un identifiant de registre de production. Une clé de déploiement limitée à un hôte est différente d’une clé privée acceptée partout. Rendez ces distinctions visibles dans les noms de comptes, les commentaires et les registres de révocation.

Évitez les secrets à longue durée de vie dans les variables d’environnement du shell. Elles fuitent facilement dans les sorties de diagnostic, les processus enfants, les rapports d’incident et les mécanismes d’inspection des processus, qui varient selon le système d’exploitation. Elles sont parfois inévitables, mais leur durée de vie doit être courte et leur chemin de lancement strictement contrôlé.

Sallyport conserve les identifiants HTTP et SSH dans son coffre chiffré et exécute l’action demandée sans donner le texte en clair à un agent compatible avec MCP. C’est utile lorsque l’agent doit effectuer un appel authentifié sans recevoir de fichier de jeton ni de clé privée dans son compte distant.

Deux contrôles indépendants sont alors en place. Le compte Unix distant détermine ce que le processus peut faire sur cette machine. La passerelle d’actions détermine si un processus d’agent peut demander une action HTTP ou SSH associée à un identifiant. Ne réduisez pas ces contrôles à un seul : une passerelle d’identifiants ne peut pas réparer un compte distant capable de lire des fichiers de production, et un compte limité ne peut pas empêcher l’utilisation d’un jeton remis directement à l’agent.

Pour l’automatisation SSH, évitez de copier votre clé privée personnelle dans /srv/agentbuild/.ssh. Créez un identifiant dédié et restreignez le serveur qui l’accepte. Si la cible distante prend en charge les commandes forcées ou les restrictions par source, utilisez-les. Sinon, limitez le compte sur cette cible. La révocation doit consister à supprimer un seul identifiant d’agent, et non à remplacer la clé que vous utilisez pour l’administration courante.

Les journaux doivent distinguer l’intention de l’exécution

Enregistrez la session de l’agent, les commandes du compte lorsque c’est possible et les modifications qu’il effectue. Des journaux indiquant seulement agentbuild logged in ne vous aideront pas à déterminer si une action a été demandée par un humain, proposée par un agent ou exécutée par un script distant.

Unix fournit déjà des éléments utiles. Les journaux d’authentification SSH identifient la clé acceptée et l’adresse source. La comptabilité des processus ou les outils d’audit peuvent suivre les exécutions, selon l’hôte. Le contrôle de version enregistre les commits et les fichiers modifiés. Les journaux de compilation enregistrent les commandes et les artefacts. Synchronisez les horodatages afin de pouvoir comparer ces informations.

Ne vous fiez pas uniquement à l’historique du shell. Les commandes non interactives peuvent ne pas y apparaître, un utilisateur peut le modifier et un agent peut lancer des outils qui créent leurs propres commandes. L’historique du shell est pratique pour le débogage, mais ce n’est pas une trace fiable.

Après une exécution, une revue utile pose quatre questions concrètes :

1. Quel contrôleur s’est authentifié avec le compte de l’agent ?
2. Quelles commandes ou tâches de compilation ont été exécutées sous cet UID ?
3. Quels fichiers en dehors de l’espace de travail prévu ont été modifiés ?
4. Quels systèmes distants et services authentifiés le processus a-t-il contactés ?

La réponse à la troisième question permet de détecter tôt l’extension progressive des permissions. Comparez les chemins accessibles en écriture par le compte avec l’espace de travail prévu avant qu’un incident ne vous impose cet inventaire. Une liste des processus peut aussi révéler des surprises : si un agent de compilation supposé bref laisse des workers en arrière-plan, ceux-ci conservent les permissions du compte après la fin de la session d’orchestration.

Sallyport enregistre les sessions des agents et chaque action dans un journal d’audit chiffré et chaîné par hachage. sp audit verify peut vérifier la chaîne hors ligne sans clé de coffre. Cette trace est plus utile encore lorsque vous conservez aussi les éléments de preuve de l’hôte distant montrant ce que l’action SSH autorisée a fait après son arrivée.

Le partage d’un compte de développeur échoue de manière prévisible

Le scénario commence souvent par une demande raisonnable : permettre à l’agent d’exécuter les mêmes tests que vous. Le développeur dirige l’agent vers un hôte distant existant et autorise sa clé SSH habituelle, car le dépôt, les caches de paquets et les dépendances de compilation fonctionnent déjà.

L’agent lance une commande de test. L’initialisation du test lit l’environnement du développeur et trouve un jeton de registre. L’installation d’une dépendance exécute un script postinstall. Ce script peut lire le répertoire personnel du développeur, examiner la configuration SSH, utiliser tout assistant d’identifiants accessible et se connecter avec les accès réseau déjà disponibles pour le développeur. Il n’est pas nécessaire d’exploiter une faille du noyau. Le processus possède simplement les mêmes droits que le développeur.

Plus tard, un script de déploiement échoue parce qu’il attend un chemin d’artefacts accessible en écriture. Quelqu’un corrige le problème avec une modification de groupe trop large. Le compte peut maintenant écrire dans un répertoire de versions. Une deuxième correction ajoute sudo sans mot de passe parce qu’un redémarrage de service est bloqué. À ce stade, la configuration supposée de l’agent a hérité d’une identité de développeur, d’un accès étendu en écriture, d’identifiants réutilisables et d’une élévation root.

Un compte dédié modifie le déroulement de cet échec. Le premier test peut échouer parce que le compte ne peut pas lire une configuration de registre ou écrire dans un ancien cache partagé. Cet échec est utile. Il vous indique qu’il faut fournir un identifiant de registre limité, créer un cache appartenant au compte ou repenser la compilation. Chaque correction devient une autorisation explicite que vous pouvez examiner.

Attendez-vous à quelques difficultés au début. Si le nouveau compte fonctionne parfaitement dès le premier essai sur une configuration de développeur mature, examinez-le attentivement. Cela peut signifier que l’hôte rend déjà trop de données et d’autorité disponibles à tous les utilisateurs locaux.

Testez la limite comme l’agent, puis supprimez ce qui surprend

Testez le compte depuis une session d’administrateur séparée avant d’autoriser le travail sans surveillance. Ne vous contentez pas de changer l’invite de votre shell en supposant que l’identité a correctement changé. Authentifiez-vous avec la clé dédiée, utilisez la vraie commande de démarrage et observez le résultat depuis l’extérieur de la session.

Lancez cette vérification d’acceptation concise après chaque changement important d’accès :

ssh -i ./agentbuild_key agentbuild@build-host 'id; umask; pwd; find ~ -maxdepth 1 -printf "%M %u %g %p\n"'
ssh -i ./agentbuild_key agentbuild@build-host 'sudo -n true; echo sudo_status=$?'
ssh -i ./agentbuild_key agentbuild@build-host 'find /srv/project-build -xdev -type f -perm -0002 -print'

La première ligne confirme l’identité, le répertoire de travail, le masque de création et les permissions du répertoire personnel. La deuxième devrait normalement renvoyer un état différent de zéro, car le compte ne devrait pas disposer d’un sudo général. La troisième recherche les fichiers ordinaires accessibles en écriture par tous dans le répertoire de projet partagé. Sur les systèmes dont find ne connaît pas -printf, utilisez plutôt ls -ld et stat.

Testez ensuite volontairement les actions refusées. Essayez de lire le répertoire personnel d’un humain, d’écrire en dehors de l’espace de travail, d’utiliser le chemin d’une clé personnelle de déploiement et d’ouvrir une session de redirection SSH si cette fonction doit être désactivée. Une restriction qui n’est jamais testée n’est qu’une intention écrite dans la configuration.

Examinez aussi le compte après de vraies tâches. Supprimez les clés autorisées obsolètes, les appartenances à des groupes, les caches, les listes de contrôle d’accès temporaires et les permissions de déploiement devenus inutiles. Le nettoyage des permissions a rarement lieu en pleine échéance. Faites-en un critère de fin de la tâche.

Commencez par créer le compte sans accès au-delà de son propre répertoire personnel et d’un dépôt de test. N’ajoutez une capacité que lorsqu’une commande réelle échoue et que vous pouvez formuler précisément la permission nécessaire. Cette approche semble plus lente pendant la configuration. Elle est beaucoup plus rapide que de devoir déterminer quelles parties d’un compte de développeur un processus autonome a copiées, utilisées ou endommagées.