Je présente GitHub comme l'historique, la sauvegarde et la capacité de reprise de mon système IA personnel. Il y a pourtant une limite que je dois rendre explicite : je n'ai encore jamais restauré l'ensemble du système après une panne ou une perte.
Mes notes sont versionnées. Les changements restent consultables. Le dépôt peut être récupéré ailleurs. Cela montre que plusieurs éléments nécessaires à une reprise existent. Cela ne prouve pas encore que je pourrais retrouver un système fonctionnel dans les conditions prévues.
Cette limite est aussi apparue pendant ma première prestation : la procédure était documentée, mais la restauration complète dans un dossier vierge n'avait pas été exécutée pendant la recette. Elle fait désormais partie de mes critères de mise en place d'un agent IA.
Une sauvegarde d'un système IA ne devrait donc pas être évaluée seulement par la présence d'une copie. Il faut vérifier ce que cette copie contient, ce qui reste dépendant d'un compte ou d'une infrastructure et si le premier usage peut réellement redémarrer.
Tant que la restauration n'a pas été testée, la reprise reste une capacité supposée.
Une sauvegarde et une reprise ne répondent pas à la même question
Une sauvegarde répond à une question simple : existe-t-il une copie exploitable de ce que l'on souhaite conserver ?
La reprise pose une question plus exigeante : peut-on remettre le système dans un état où une personne peut de nouveau l'utiliser dans les limites prévues ?
Cette distinction compte pour un système IA personnel, parce que son fonctionnement ne repose pas sur un fichier unique. Il relie une mémoire, un agent, des outils, des permissions, une interface et des comptes externes. Une partie peut être disponible pendant qu'une autre bloque l'ensemble.
Le NIST traite la reprise comme un travail de planification qui commence par l'évaluation des systèmes et des opérations, puis par la définition des exigences et des priorités. Cette recommandation vise des organisations, mais le raisonnement reste utile à une personne seule : tous les éléments ne méritent pas le même niveau de protection et tous ne sont pas nécessaires pour reprendre le premier usage.
Il faut donc commencer par définir l'état minimal attendu. Dans mon cas, une restauration réussie ne signifierait pas que chaque automatisation secondaire fonctionne immédiatement. Elle devrait d'abord me permettre de retrouver ma mémoire de travail, de relancer l'agent dans un environnement maîtrisé et d'exécuter un usage borné sans contourner les permissions.
Ce que GitHub conserve réellement
GitHub indique qu'un dépôt Git contient les fichiers et dossiers d'un projet ainsi que l'historique des révisions. Sa documentation décrit notamment la création d'un clone miroir et sa restauration vers un dépôt distant.
C'est utile pour mon système. Mon vault Obsidian reste composé de fichiers lisibles. Git conserve leurs versions et permet de revenir sur une modification. La configuration et la documentation qui ont été placées dans le dépôt peuvent suivre le même chemin.
Mais un dépôt ne contient automatiquement que ce qui y a été enregistré.
Il ne recrée pas un VPS. Il ne réactive pas un compte Discord ou GitHub. Il ne récupère pas un secret volontairement exclu du dépôt. Il ne garantit pas qu'une dépendance externe existe encore dans la même version. Il ne prouve pas non plus que la documentation permettrait à quelqu'un de comprendre l'ordre des opérations.
La documentation de GitHub montre elle-même que le mot « sauvegarde » recouvre des contenus différents. Certaines archives excluent des données associées au dépôt et ne disposent pas d'une méthode documentée de restauration sur GitHub. Le choix d'un mécanisme dépend donc de ce que l'on veut réellement récupérer.
Dans un système IA personnel, GitHub peut fournir une partie solide de la reprise. Le confondre avec la reprise complète laisserait plusieurs dépendances invisibles.
Les six éléments à retrouver
Avant de tester une restauration, je dois inventorier ce qui rend mon système utilisable. Six ensembles apparaissent.
1. La mémoire possédée
Les notes, décisions, sources et documents de référence doivent revenir avec une structure compréhensible. Récupérer les fichiers sans leurs liens, leur historique ou leurs conventions peut produire une archive lisible, mais difficile à utiliser par l'agent.
Il faut aussi distinguer les données irremplaçables des contenus reconstructibles. Une décision actuelle, une note personnelle ou un document client autorisé ne se traite pas comme un cache temporaire ou une synthèse que l'on peut recalculer.
2. Les règles et les permissions
Un agent restauré avec des accès plus larges que prévu n'est pas revenu dans le même état. Les actions automatiques, les actions soumises à validation et les actions interdites doivent rester séparées.
La reprise doit donc préserver les règles, mais aussi permettre de les tester. Lire une note autorisée ne suffit pas. Il faut également vérifier qu'une demande hors périmètre est refusée et qu'une action sensible attend toujours une validation humaine. La construction de ces trois régimes est détaillée dans la grille de permissions d'un agent IA.
3. L'environnement d'exécution
L'agent a besoin d'un endroit où fonctionner : serveur, dépendances, versions compatibles et processus de démarrage. Sauvegarder les connaissances sans pouvoir relancer l'environnement conserve le capital informationnel, pas le service qui l'utilise.
À l'inverse, reconstruire un serveur vide ne suffit pas davantage. L'environnement et la mémoire doivent être rapprochés dans un ordre documenté.
4. Les comptes et les accès
Les comptes appartiennent à la personne qui utilise le système. Cette propriété réduit la dépendance au prestataire, mais elle ne dispense pas d'organiser la reprise des accès.
Les identifiants et secrets ne devraient pas être stockés en clair dans le dépôt de sauvegarde. GitHub recommande d'éviter de coder les secrets dans les fichiers et d'utiliser des variables d'environnement ou un service de gestion adapté. Il faut toutefois savoir quels accès seront nécessaires, qui peut les rétablir et comment remplacer un secret compromis ou perdu.
Un dépôt intact ne sert à rien si personne ne peut atteindre le compte qui l'héberge. La récupération des comptes fait donc partie du scénario, même si les secrets suivent un circuit distinct.
5. Les connexions entre les composants
Mon système relie Hermes, Discord, Obsidian et GitHub. Une restauration complète doit vérifier que ces composants communiquent de nouveau, avec les mêmes frontières.
Le test ne doit pas se limiter à constater que chaque outil s'ouvre séparément. Il doit suivre un usage de bout en bout : une demande entre par l'interface, l'agent consulte une source autorisée, prépare une sortie, respecte la validation et conserve uniquement ce qui était prévu.
6. La documentation de reprise
Une procédure existe pour être utilisée dans une situation dégradée. Elle doit nommer les prérequis, l'ordre des étapes, les points de contrôle et les cas où il faut s'arrêter.
Si la reprise dépend uniquement de la mémoire de la personne qui a mis le système en place, le client possède peut-être les fichiers sans posséder la capacité de continuer seul. La documentation fait donc partie de l'autonomie livrée.
Un test de restauration doit partir d'un incident précis
« Vérifier les sauvegardes » reste trop vague. Un test devient utile lorsqu'il part d'un scénario identifiable.
Par exemple :
- le vault local a été supprimé ou corrompu ;
- le VPS doit être remplacé ;
- un compte n'est plus accessible ;
- une configuration récente provoque un comportement indésirable ;
- la personne qui a réalisé la mise en place n'est pas disponible.
Chaque scénario mobilise des éléments différents. Restaurer une note supprimée teste l'historique. Reconstruire le système sur un nouvel environnement teste la documentation, les dépendances et les accès. Continuer sans le prestataire teste la propriété réelle du système.
Pour mon premier test, le scénario doit rester borné. Je n'ai pas besoin de provoquer une panne sur le système utilisé chaque jour. Je peux repartir dans un environnement isolé, depuis les éléments sauvegardés, puis vérifier un usage représentatif. La grille pour transformer cet usage en scénarios vérifiables, arrêts compris, est décrite dans la méthode pour tester un agent IA.
Les critères d'une restauration réussie
Avant de commencer, il faut écrire ce qui permettra de conclure. Sans critères, le test risque de s'arrêter dès que les fichiers réapparaissent.
Je retiendrais au minimum les vérifications suivantes :
- les fichiers attendus sont présents et lisibles ;
- l'historique permet de retrouver une version antérieure ;
- l'agent démarre dans l'environnement restauré ;
- il accède uniquement aux sources prévues ;
- un usage autorisé produit la sortie attendue ;
- une action soumise à validation ne part pas seule ;
- une action interdite est effectivement refusée ;
- une source manquante produit un arrêt ou un signalement, pas une invention silencieuse ;
- une autre personne disposant de la documentation peut comprendre la reprise.
Cette dernière vérification mérite une attention particulière dans une prestation. Un système ne devient pas autonome pour le client parce que le prestataire sait le reconstruire. Il le devient lorsque les comptes, les sauvegardes et la procédure permettent au client de continuer sans dépendance imposée.
Tester sans mettre le système principal en danger
Un test de restauration ne doit pas détériorer ce qu'il cherche à protéger.
L'environnement de test doit donc être séparé du système utilisé au quotidien. Les actions externes peuvent rester désactivées ou redirigées vers des espaces fictifs. Les secrets peuvent être remplacés par des accès de test lorsque c'est possible. Les données sensibles doivent être minimisées.
Il faut également conserver l'état de départ. Si le test modifie la sauvegarde unique ou pousse une configuration expérimentale vers l'environnement principal, il crée un nouveau risque.
La CISA recommande de tester régulièrement la disponibilité et l'intégrité des sauvegardes dans un scénario de reprise, et de tester les procédures elles-mêmes. Son guide vise notamment les risques liés aux rançongiciels. Pour un système personnel, le périmètre et les menaces diffèrent, mais le principe reste valable : la présence d'une copie ne prouve ni son intégrité ni la possibilité de l'utiliser au moment nécessaire.
Le test doit laisser une trace simple : scénario, éléments utilisés, résultat de chaque contrôle, blocages rencontrés et corrections à apporter. Cette trace évite de transformer une réussite partielle en conclusion générale.
Ce que mon système prouve aujourd'hui, et ce qu'il ne prouve pas encore
Je peux affirmer que mon système utilise un vault Obsidian composé de fichiers lisibles, versionnés avec Git et synchronisés vers GitHub. Je peux consulter l'historique, récupérer le dépôt et documenter les composants nécessaires à son fonctionnement.
Je ne peux pas encore affirmer qu'une restauration complète a été vérifiée. Je ne l'ai jamais réalisée.
Cette limite change ma manière de présenter le système. GitHub constitue bien un mécanisme de sauvegarde et fournit des éléments nécessaires à la reprise. La capacité de reprise complète reste à éprouver dans un environnement isolé, avec des critères définis à l'avance.
Ce constat ne rend pas la sauvegarde inutile. Il évite de lui faire promettre davantage que ce qui a été observé.
La prochaine étape de mon propre système est donc claire : choisir un scénario borné, restaurer la mémoire et l'environnement nécessaires à un premier usage, puis tester les permissions, l'échec et la documentation. Le résultat pourra ensuite devenir une preuve, qu'il révèle une reprise satisfaisante ou des dépendances oubliées.
Ce qu'un solopreneur peut vérifier dès maintenant
Vous n'avez pas besoin d'attendre une panne pour comprendre votre situation. Prenez l'usage IA auquel vous tenez le plus et posez quelques questions :
- où se trouvent ses connaissances et ses fichiers de référence ?
- existe-t-il une copie séparée et accessible ?
- l'historique permet-il de corriger une suppression ou une mauvaise modification ?
- quels comptes et services sont nécessaires pour redémarrer ?
- qui possède ces comptes ?
- les permissions peuvent-elles être reconstruites et testées ?
- la procédure reste-t-elle compréhensible sans la personne qui a réalisé la mise en place ?
- quel résultat minimal prouverait que l'usage fonctionne de nouveau ?
Si certaines réponses manquent, le problème n'est pas nécessairement l'absence de sauvegarde. Il peut se trouver dans les accès, la documentation, les dépendances ou l'absence de critères de reprise.
C'est précisément pour cette raison qu'un système IA personnel doit associer mémoire, permissions, validation humaine et reprise. Le premier cas d'usage fournit un bon périmètre de test : il est assez petit pour être reconstruit et assez utile pour montrer si le système est réellement revenu.
Une sauvegarde doit gagner le droit d'être appelée capacité de reprise
La sauvegarde protège des éléments. La restauration vérifie qu'ils peuvent redevenir un système utilisable.
Dans mon cas, cette vérification reste à faire. Je préfère l'écrire clairement plutôt que de transformer une architecture cohérente en preuve qu'elle n'a pas encore produite.
Le prochain test devra répondre à une question simple : si je repars depuis ce que j'ai sauvegardé, puis-je retrouver un premier usage fonctionnel, avec les mêmes permissions et une procédure que je ne suis pas le seul à comprendre ?
Tant que je n'ai pas cette réponse, j'ai une sauvegarde structurée et une hypothèse de reprise. Pas encore une restauration vérifiée.