Votre premier backup GitHub
en moins de 10 minutes.

CYBBACK propose deux façons de démarrer. Les deux débloquent l'ensemble des fonctionnalités GitHub.

Option A — Essai gratuit

1. Ouvrez cybback.com/essai-gratuit.
2. Renseignez votre email professionnel, votre société et un mot de passe. Cliquez sur Démarrer l'essai gratuit.
3. Confirmez via l'email de vérification.
4. Sur l'écran de sélection de l'essai, choisissez GitHub. Votre espace de travail d'essai est provisionné instantanément.

Option B — Licence payante (Stripe Checkout)

1. Allez sur cybback.com/tarifs et choisissez le plan GitHub correspondant au nombre de propriétaires GitHub (utilisateur / organisations) à protéger.
2. Cliquez sur S'abonner. Stripe Checkout accepte les cartes, SEPA et la facturation sur les plans annuels.
3. Votre licence est active immédiatement — visible sous Compte → Abonnement.

CYBBACK lit vos données GitHub via un Personal Access Token. Choisissez le type adapté à votre gouvernance — les PAT classiques et fine-grained sont tous deux pris en charge.

Option A — PAT classique (le plus simple)

1. Ouvrez github.com/settings/tokens/new.
2. Note : CYBBACK Backup. Expiration : 90 jours (programmez un rappel d'agenda pour le renouveler).
3. Cochez le scope repo (couvre tout le contenu des repositories, issues, PRs, releases, webhooks). Ajoutez read:org si vous voulez sauvegarder les repos détenus par une organisation.
4. Cliquez sur Generate token et copiez la valeur (elle ne sera plus affichée).

Option B — PAT fine-grained (recommandé pour les organisations)

1. Ouvrez github.com/settings/personal-access-tokens/new.
2. Resource owner : votre utilisateur, ou l'organisation que vous voulez sauvegarder.
3. Repository access : All repositories ou des repos spécifiques.
4. Permissions (Repository) : Contents: Read, Metadata: Read, Issues: Read, Pull requests: Read, Webhooks: Read, Actions: Read & write (le write n'est nécessaire que pour restaurer les variables).
5. Cliquez sur Generate et copiez la valeur.

Coller le PAT dans CYBBACK

1. Ouvrez app.cybback.com/dashboard/github-backup → Configuration.
2. Collez le PAT et cliquez sur Valider. CYBBACK appelle GET /user pour confirmer que le token fonctionne et récupère votre nom d'utilisateur + les organisations accessibles.
3. Le PAT est chiffré (AES-256-GCM) et stocké dans le vault CYBBACK.

CYBBACK peut sauvegarder tous les repositories visibles par le PAT, ou seulement un sous-ensemble choisi. Vous pouvez aussi ajuster les catégories de données capturées par backup.

Périmètre

• Tous mes repos (par défaut) — chaque repo auquel le PAT a accès (propre + collaborateur + membre d'organisation).
• Sélection manuelle — cliquez sur Charger les repos, puis cochez par propriétaire ou par repo individuel. Utile lorsque vous voulez protéger uniquement les repos de production et exclure vos forks personnels.

Ce qu'il faut inclure

Chaque backup peut inclure ou exclure ces catégories indépendamment :

• Code source — historique git complet (git bundle --all), toutes les branches et tags.
• Paramètres — visibilité, branche par défaut, branches protégées, topics.
• Équipes — nom d'équipe, slug, niveau de permission (repos d'organisation uniquement).
• Webhooks — URL, événements, hash secret, état actif.
• Workflows — métadonnées des définitions de workflows Actions. Les fichiers YAML eux-mêmes vivent dans le code bundle.
• Variables Actions — nom + valeur (restaurables via API).
• Noms des secrets Actions — noms uniquement. GitHub n'expose jamais les valeurs via API ; nous conservons les noms pour que vous sachiez quoi recréer après restauration.
• Issues / Pull requests / Releases — snapshots en lecture seule (état, labels, commentaires, revues).

Vous voulez une souveraineté totale sur vos données ? Pointez CYBBACK vers votre bucket S3-compatible — AWS S3, GCS, Scaleway, OVH, Wasabi, MinIO. Vos données, votre hébergeur, votre région.

Provisionner le bucket

1. Dans votre provider S3, créez un bucket privé (pas d'accès public, versioning recommandé).
2. Créez une clé d'accès / clé secrète avec des permissions limitées à ce bucket.
3. Notez votre URL d'endpoint et votre région.

Configurer CYBBACK

1. Ouvrez Dashboard → Stockage.
2. Sélectionnez Mon propre stockage S3.
3. Remplissez le formulaire, cliquez sur Tester la connexion, puis Enregistrer.

• Actions IAM requises : PutObject, GetObject, DeleteObject, ListBucket.
• Résilience : CYBBACK stocke un snapshot chiffré des credentials S3 avec chaque backup. Les anciens backups restent restaurables même si vous changez de provider.
• Usage disque : un mirror type de 100 repos actifs (~2 Go cumulés) occupe ~500 Mo sur S3 grâce à la compression naturelle de git.

Tout est configuré. Il est temps de faire votre premier snapshot GitHub — manuellement pour une tranquillité immédiate, puis planifiez des runs récurrents.

Backup manuel

1. Revenez sur l'onglet Dashboard.
2. Cliquez sur Lancer un backup maintenant. Le job apparaît avec le statut en attente, puis en cours.
3. La progression est diffusée en direct : PAT validé, repos énumérés, bundles uploadés, snapshots de métadonnées enregistrés.

Planifier les backups automatiques

1. Depuis Dashboard → Planifications, cliquez sur Nouvelle planification.
2. Service : GitHub. Fréquence : Quotidien / Hebdomadaire / Personnalisé (cron).
3. Choisissez une plage horaire (ex. 04h00 Europe/Paris) et cliquez sur Enregistrer.

Suivre vos backups

• Temps réel : la page Événements diffuse chaque opération de tous les services via SSE.
• Notifications : alertes succès / échec / drift par email, Slack et webhooks.
• Drift detection : alertes sur les patterns suspects — suppressions massives de repos, force-pushes effaçant l'historique, changements soudains de permissions entre les runs.

CYBBACK restaure depuis n'importe quel snapshot GitHub précédent. Repoussez un seul repo vers son propriétaire d'origine, forkez-le vers un autre utilisateur/organisation, ou restaurez l'intégralité du compte en cas de compromission.

Le flow de restauration en 3 étapes

1. Sélection. Ouvrez le snapshot, parcourez les repos, cochez ce que vous voulez récupérer. Choisissez les catégories à restaurer (code, paramètres, webhooks, workflows, variables).
2. Options. Choisissez votre filet de sécurité :
   • Dry-run — simulation, aucune écriture vers l'API GitHub, aucun git push.
   • Force overwrite — git push --mirror --force, remplace l'historique cible. À n'utiliser que si vous avez confiance dans le snapshot.
   • Propriétaire cible — laissez vide pour restaurer vers le propriétaire d'origine, ou indiquez un autre utilisateur/organisation. Combinez avec un suffixe de nom de repo (-restored) pour éviter les collisions.
3. Exécution. Le worker asynchrone télécharge le bundle depuis S3, pousse via git push --mirror, puis recrée les webhooks + variables Actions via REST. Un résumé indique ce qui a été créé, mis à jour ou ignoré.

Bonnes pratiques

• Commencez toujours par un dry-run — le worker indique exactement ce qu'il pousserait sans toucher à GitHub.
• Restaurez d'abord vers un propriétaire alternatif pour les scénarios DR majeurs. Validez le résultat, puis planifiez une bascule contrôlée.
• Le force overwrite est irréversible sur la cible. L'historique du repo d'origine est perdu après un push --force réussi.