Les agents de programmation ont désormais accès au shell de véritables machines. Ils exécutent des migrations, nettoient des répertoires, réinitialisent des branches et suppriment des fichiers qui semblent inutiles. La plupart du temps, c'est exactement ce qu'on leur demande. Mais un nouveau type d'incident est apparu, au point que la sauvegarde des agents IA constitue un sujet à part entière : toute copie accessible à l'agent peut être détruite par celui-ci, souvent pendant qu'il accomplit une tâche légitime.
Ce risque n'a rien d'une hypothèse inventée pour vendre du stockage. Quiconque utilise des agents sur une copie de travail active en a déjà vu un supprimer ce qu'il fallait conserver. Cette page présente un modèle de sauvegarde qui peut résister à ce scénario lorsqu'il est correctement configuré, tout en précisant ses limites.
Pourquoi votre sauvegarde actuelle n'est pas adaptée aux agents IA
Le modèle de menace classique prévoit une panne matérielle, une erreur humaine ou un rançongiciel. Les agents se trouvent à la croisée de ces trois risques : ils agissent avec vos identifiants, à la vitesse d'une machine et pour des motifs qui paraissent plausibles.
Un lecteur réseau monté est visible par tout processus exécuté sous votre compte. Il en va de même d'un dossier synchronisé, d'un lecteur mappé ou d'un espace de stockage objet dont les clés figurent dans un fichier d'environnement lisible par l'agent. Si celui-ci considère un répertoire comme un ancien résultat de compilation, décide de réinitialiser un dépôt ou cherche à libérer de l'espace, tout ce qu'il voit peut être concerné. La synchronisation propage alors la suppression vers la copie sur laquelle vous comptiez, conformément à son fonctionnement normal.
La différence essentielle ne tient donc pas au choix entre cloud et stockage local. Elle tient à l'accessibilité de la copie depuis l'environnement dans lequel l'agent fonctionne.
Le bon modèle : envoyer, sans jamais synchroniser
C'est le point le plus souvent mal compris, et il mérite une section à lui seul.
La synchronisation est bidirectionnelle par nature. Une suppression locale est répercutée à distance, ce qui convient aux fichiers de travail mais peut détruire une archive. De nombreux dispositifs présentés comme des sauvegardes sont en réalité des synchronisations : ils protègent d'un disque défaillant, pas nécessairement d'une suppression. Les recommandations nationales sur la résilience face aux rançongiciels le rappellent depuis des années : selon les conseils de la CISA, une copie doit être isolée du système qu'elle protège. Un agent disposant d'un accès au shell est simplement une nouvelle façon, particulièrement rapide, d'enfreindre ce principe.
Une sauvegarde adaptée envoie de nouvelles données sans reproduire les suppressions. Avec des destinations horodatées ou datées, chaque exécution ajoute une copie au lieu d'en remplacer une autre. Dans de nombreuses configurations, conserver trente copies quotidiennes d'un export de base de données coûte moins cher que le temps consacré à expliquer pourquoi aucune restauration n'est possible.
La séparation des identifiants est essentielle
Le mécanisme n'a rien de spectaculaire, ce qui est une qualité pour une sauvegarde. Il faut un chemin d'envoi à sens unique et des identifiants auxquels l'environnement de travail n'a jamais accès.
Drive permet de créer dans le tableau de bord des mots de passe d'application associés à un appareil et révocables séparément. Une configuration robuste utilise un identifiant réservé à la sauvegarde, stocké uniquement sur la machine ou dans la tâche planifiée chargée de l'envoi : jamais dans le répertoire du projet, dans un fichier d'environnement partagé ni dans un emplacement confié à l'agent. L'agent reste libre d'agir sur la copie de travail, mais ne dispose d'aucun accès à la destination.
Si la tâche d'envoi fonctionne sur la même machine que l'agent, conservez l'identifiant hors de l'arborescence du projet et protégez-le avec des droits système minimaux. Sur une autre machine, comme un petit appareil toujours allumé ou un exécuteur planifié, la séparation est encore plus nette puisqu'aucun système de fichiers n'est partagé. Dans les deux cas, la copie ne résiste que si l'agent et les processus qu'il contrôle ne peuvent ni lire ni obtenir cet identifiant.
Ce que cette sauvegarde protège, et ce qu'elle ne protège pas
Ici, la précision compte davantage qu'un discours rassurant.
Elle peut protéger contre la suppression ou l'écrasement de fichiers par un agent dans l'environnement de travail, le nettoyage d'un répertoire par un script, une réinitialisation accidentelle du dépôt et une erreur humaine ordinaire, à condition qu'une copie complète et isolée ait déjà été transférée. Elle couvre également le cas où une synchronisation propage fidèlement une suppression involontaire.
Elle ne protège pas contre une personne qui possède l'accès à votre tableau de bord et le second facteur, car celle-ci peut révoquer les mots de passe d'application et vider la corbeille. Elle ne protège pas davantage contre la compromission de la destination, une mauvaise politique de conservation ou la suppression volontaire de l'archive. Enfin, elle ne remplace pas le contrôle de version du code source, conçu pour un autre besoin.
La sauvegarde des agents IA n'est qu'une couche. Elle ne constitue pas à elle seule un programme de sécurité, et prétendre le contraire serait trompeur.
Les éléments qui méritent d'être envoyés
La liste est plus courte qu'on pourrait le croire, car une grande partie d'un répertoire de travail peut être reproduite.
- Exports de base de données. Ce sont les données qui ne peuvent réellement pas être recréées. Effectuez une copie nocturne datée et conservez-la selon les limites de votre offre et votre politique de rétention.
- Fichiers d'environnement et de configuration. Petits, souvent oubliés et pénibles à reconstruire, ils peuvent aussi contenir des secrets. Chiffrez-les, limitez strictement l'accès et prévoyez la rotation des identifiants.
- Contenu téléversé par les utilisateurs. Il ne se trouve pas dans le contrôle de version, ne peut pas être régénéré et passe souvent inaperçu jusqu'à sa disparition.
- Artefacts générés importants. Par exemple, des rapports et des exports produits par un processus qui a changé depuis.
Le code source n'a généralement pas sa place ici lorsqu'un dépôt git distant et correctement protégé en conserve déjà l'historique. L'inclure ne pose pas de problème, mais ce n'est pas l'objectif principal de cette couche.
À quoi ressemble une tâche nocturne
La mise en œuvre peut rester courte et facile à auditer, ce qui réduit sa maintenance sans garantir pour autant qu'elle fonctionnera toujours.
Une tâche planifiée s'exécute une fois par nuit. Elle exporte la base de données dans un fichier temporaire, ajoute la date au nom, l'envoie vers un chemin daté sur le lecteur, vérifie le succès du transfert, puis supprime la copie temporaire locale. Les fichiers de configuration et le contenu téléversé suivent le même chemin. La tâche utilise son propre identifiant, ne récupère aucun secret dans le répertoire du projet et ne comporte aucune fonction de suppression distante.
Deux détails distinguent une sauvegarde utile d'une tâche qui échoue en silence. Premièrement, le chemin de destination doit inclure la date afin que chaque exécution crée une nouvelle copie : téléverser chaque nuit sous le même nom ne laisse qu'une seule sauvegarde, celle de la nuit précédente, insuffisante pour un problème découvert le jeudi. Deuxièmement, tout échec doit déclencher une alerte vérifiée. Une sauvegarde silencieusement interrompue depuis six semaines peut donner une fausse impression de sécurité.
Tester la restauration
Une copie qui n'a jamais été restaurée reste une hypothèse. C'est souvent le maillon faible des dispositifs de sauvegarde.
Une fois par trimestre, téléchargez une copie et restaurez-la réellement dans un environnement jetable. Vérifiez trois points : l'intégrité du téléchargement, l'exhaustivité du fichier plutôt qu'un transfert interrompu à mi-parcours, et la maîtrise de la procédure. Ce dernier point est essentiel, car un incident n'est pas le bon moment pour découvrir le mode d'emploi.
La restauration valide aussi un aspect propre à cette configuration : l'accès à la destination et la procédure de récupération fonctionnent toujours. Elle ne prouve pas à elle seule que l'identifiant d'envoi n'a pas été révoqué ou remplacé sans mise à jour de la tâche. Surveillez donc séparément chaque téléversement et son horodatage.
Combien de temps conserver les copies
La rétention dépend des risques, des obligations et du budget de stockage, pas d'une règle technique universelle. La durée nécessaire est souvent plus longue que prévu.
L'incident n'est pas toujours découvert immédiatement. La suppression d'un répertoire peut être visible en quelques heures, tandis qu'une altération discrète des données ou la disparition d'un élément utilisé seulement chaque mois peut passer inaperçue pendant des semaines. Trente copies quotidiennes offrent un mois d'historique. Leur coût dépend toutefois du volume réel, de la croissance des données et de l'offre choisie.
Une pratique courante consiste à conserver chaque copie quotidienne pendant un mois, puis une copie mensuelle pendant un an. Cela limite la croissance tout en gardant un historique plus ancien. Quelle que soit la règle choisie, appliquez-la avec une tâche distincte, une identité séparée et des contrôles adaptés. Donner à l'outil d'envoi un droit de suppression recréerait le risque que cette architecture cherche à réduire.
Où stocker les sauvegardes
Drive est rattaché au même compte que la messagerie, ce qui peut réduire le nombre de services et de factures. Dans l'offre décrite ici, l'extension commence à 250 GB pour $3.20 par mois et son curseur va jusqu'à 100 TB, sous réserve des conditions et limites du forfait. L'absence de frais de sortie annoncée pour cette offre est intéressante lors d'une restauration, mais il convient de vérifier les conditions applicables au compte.
Selon la configuration du compte, le stockage peut être mutualisé ou attribué par boîte aux lettres afin de séparer la destination des autres usages. Les téléversements sont possibles via WebDAV ou l'API lorsque ces méthodes sont prises en charge. Les détails de montage figurent dans le guide WebDAV. Des dossiers peuvent également être partagés avec un autre compte pour faciliter une restauration, comme l'explique le fonctionnement des liens de partage. Ce partage ne remplace ni des autorisations minimales, ni le chiffrement, ni un journal d'audit.
Le principe reste simple : un dossier daté, un identifiant absent de l'environnement de travail et une tâche qui ne fait qu'ajouter. Les agents rendent à nouveau essentielle une ancienne règle : la copie utile lors d'un incident est celle à laquelle rien dans l'environnement de travail ne peut s'authentifier, dans les limites de l'isolation réellement mise en place.
