GitHub devrait être la priorité n° 1 de vos sauvegardes

Demandez à la plupart des équipes informatiques ou chargées des plateformes quelle est leur principale priorité en matière de sauvegarde, et vous obtiendrez toujours la même liste : les e-mails, les partages de fichiers, les logiciels ERP et, bien sûr, l’infrastructure (matériel, logiciels et composants réseau). GitHub se situe généralement quelque part au milieu, ou est écarté avec l’argument suivant : « GitHub se réplique tout seul, tout va bien. » 

Ce classement est un vestige d’une autre époque. GitHub est désormais le système d’enregistrement le plus précieux et le plus dynamique au sein de la plupart des organisations d’ingénierie, et il doit figurer en tête de la liste des priorités de sauvegarde, avant les e-mails, les partages de fichiers et la plupart des applications hébergées dans le cloud. 

Pourquoi GitHub s’est hissé en tête 

Le contenu de GitHub a évolué. Une organisation GitHub moderne contient le plan opérationnel de l’entreprise : code d’application, infrastructure en tant que code, pipelines CI/CD, configurations de déploiement, guides d’exploitation, politiques de sécurité, SDK destinés aux clients, invites d’IA et, de plus en plus, les définitions d’agents qui automatisent les tâches quotidiennes des ingénieurs. Autrefois, perdre un dépôt signifiait perdre un peu de code. Aujourd’hui, perdre un dépôt peut signifier perdre les spécifications relatives au fonctionnement de l’entreprise. 

La vélocité a considérablement augmenté. Avec Copilot, Cursor et Claude Code intégrés aux flux de travail quotidiens, une organisation de 50 ingénieurs qui produisait 200 commits par jour en 2023 en produit désormais régulièrement entre 600 et 1 000. Les agents effectuent des commits pendant la nuit. Les agents effectuent des commits pendant le week-end. Ce qui prenait auparavant une semaine à créer peut désormais l’être en une journée, ce qui signifie également qu’un seul incident destructeur peut anéantir plus de travail que jamais auparavant. 

Les modes de défaillance se sont aggravés. Les protections natives de GitHub (protection des branches, réplication, délai de 90 jours pour la suppression d’un dépôt) sont bien réelles, mais limitées. Elles ne permettent pas de remédier à un « force push » que GitHub considère comme légitime, car il provient d’un compte de service authentifié. Elles ne permettent pas de remédier à un agent qui réécrit le répertoire .github/workflows pour créer une boucle détruisant les artefacts de publication. Elles ne permettent pas non plus de remédier à l’utilisation d’un jeton d’accès personnel compromis pour supprimer 200 branches à 3 h du matin. 

Quelle sauvegarde GitHub doit réellement résister 

Les événements destructeurs qui comptent ne sont généralement pas de nature malveillante. Ils sont banals, et l’ère des agents les a rendus plus courants : 

• Un agent de nettoyage supprime des branches qui semblaient obsolètes mais ne l’étaient pas. 
• Un agent de refactorisation effectue un push forcé vers la branche principale après un rebase raté. 
• Un script de migration réécrit l’historique d’une douzaine de dépôts. 
• Un jeton d’agent compromis est utilisé pour supprimer des branches, des balises ou des versions avant que quiconque ne s’en aperçoive. 
• Un workflow d’intégration continue exécute une commande Git destructive générée par un agent. 

Dans tous les cas, l’action semble légitime aux yeux de GitHub. Elle a été authentifiée. Elles ont été autorisées. Les protections propres à GitHub n’ont aucun moyen de savoir que le push était erroné. 

Un exemple théorique 

Une entreprise de fintech de taille moyenne gère 18 dépôts sur GitHub, sauvegardés chaque nuit. Elle dispose d’un agent de codage qui exécute des tests et applique des corrections automatisées à l’échelle de l’organisation, authentifié via un compte de service disposant de droits d’administrateur sur le monorepo principal, car la mise en place d’autorisations plus granulaires était prévue pour le trimestre suivant. 

Samedi à 2 h du matin, l’agent rencontre un bug dans sa logique de rebase lors du traitement d’une importante pull request. Il effectue un push forcé d’un historique réécrit vers la branche « main », supprimant ainsi 142 commits de la semaine précédente, dont trois correctifs de production déjà en cours d’exécution en production. Personne ne surveille le processus. Aucune règle de protection de branche n’a bloqué cette opération de push. 

L’équipe s’en rend compte lundi matin. La dernière sauvegarde valide a été effectuée vendredi à minuit. Entre ce snapshot et l’incident, l’agent avait fusionné 47 PR. Les 47 ont disparu du contrôle de source. Les correctifs sont toujours en production, mais leur source de référence n’existe plus dans aucun dépôt. 

La restauration prend trois jours. Deux des correctifs ne peuvent pas être reconstruits correctement et doivent être réécrits à partir de zéro. Une sauvegarde toutes les heures aurait limité la perte à 47 minutes de travail. 

Ce qu’il faut rechercher dans une solution de sauvegarde GitHub 

Si GitHub est votre priorité n° 1 en matière de sauvegarde, la solution doit répondre à quatre critères : 

Une fréquence de sauvegarde intensive. Les outils de sauvegarde utilisent le terme RPO (objectif de point de reprise). En termes simples, il s’agit de la quantité de travail que vous êtes prêt à perdre en cas de panne, mesurée en temps. Si votre sauvegarde s’effectue chaque nuit, votre RPO est de 24 heures. Pour GitHub à l’ère des agents, une sauvegarde nocturne est trop lente. Une sauvegarde toutes les heures est le minimum requis. Une sauvegarde toutes les trente minutes est acceptable pour les monorepos critiques. Demandez à n’importe quel fournisseur quelle est sa cadence minimale, et si celle-ci s’applique à l’ensemble du dépôt (y compris les tickets, les PR et les paramètres) ou uniquement au code. 

Couverture complète. Se contenter de sauvegarder le code transforme un incident de quatre heures en un incident de quatre jours. Vous avez besoin des tickets, des pull requests, des discussions, des workflows Actions, des versions, des objets LFS, des règles de protection des branches et des paramètres au niveau de l’organisation, tels que l’appartenance à une équipe et les installations d’applications. La perte du répertoire .github/workflows à elle seule peut entraîner la perte de la configuration des agents dont vous dépendez. 

Immuabilité. Un jeton d’administrateur compromis capable de supprimer un dépôt peut souvent supprimer la sauvegarde également, si le système de sauvegarde fait confiance aux mêmes identifiants. Les copies isolées physiquement ou verrouillées au niveau des objets ne sont pas facultatives. Elles font la différence entre une mauvaise journée et un cauchemar consistant à tout reconstruire à partir des ordinateurs portables des développeurs. 

Récupération testée. Restaurez un dépôt non critique de bout en bout au moins une fois par trimestre. Mesurez le temps que cela prend réellement. Une sauvegarde à partir de laquelle vous n’avez jamais effectué de restauration n’est qu’une supposition, pas un plan. 

Le changement 

La plupart des organisations sauvegardent GitHub en partant du principe qu’il s’agit d’un dépôt de code auquel sont associés quelques artefacts secondaires. Ce n’est plus ce qu’est GitHub. C’est le système opérationnel le plus dynamique que la plupart des entreprises exploitent, et la vitesse à laquelle il génère de la valeur a dépassé les capacités de sauvegarde dont la plupart des équipes ont hérité. 

Placez GitHub en tête de la liste des priorités. Une cadence de sauvegarde intensive, une couverture complète, l’immuabilité et une restauration testée sont les caractéristiques qui concrétisent cette priorité. Sans elles, « nous sauvegardons GitHub » n’est qu’une case à cocher, et non un véritable plan.