Sauvegarder ses projets de développement : Git, CI/CD et stratégies de backup

1. Les dépôts Git : GitHub, GitLab et auto-hébergé

Git est le fondement de toute stratégie de sauvegarde du code source. Il enregistre chaque modification avec son auteur, sa date et un message de commit, permettant de remonter dans le temps à n'importe quel état du projet. Mais Git seul ne suffit pas : encore faut-il pousser régulièrement vers un dépôt distant et choisir soigneusement ses services d'hébergement.

GitHub reste la plateforme dominante avec plus de 100 millions de développeurs et une intégration native avec la quasi-totalité des outils DevOps. GitHub Actions, GitHub Packages et l'hébergement des Pages sont inclus dans le plan gratuit. Les dépôts privés sont illimités. Le principal risque : dépendance à un service tiers et, dans de rares cas, suspension de compte.

GitLab se distingue par sa suite DevOps intégrée (CI/CD, container registry, issue tracker, deploy board) dans une seule plateforme. GitLab.com est gratuit pour les projets publics et privés. GitLab CE (Community Edition) peut être auto-hébergé sur vos propres serveurs, ce qui élimine la dépendance à un tiers et donne un contrôle total sur vos données.

Auto-hébergement avec Gitea ou Forgejo

Pour les équipes souhaitant une souveraineté totale sur leur code, Gitea et son fork communautaire Forgejo sont des alternatives légères, déployables en quelques minutes avec Docker. Ils supportent les webhooks, les Actions compatibles GitHub Actions, la gestion des utilisateurs et les dépôts privés illimités. Un VPS à 5 euros par mois suffit pour héberger une instance Gitea pour une petite équipe.

L'auto-hébergement impose cependant une responsabilité : vous devez sauvegarder l'instance Git elle-même (dossier de données, base de données SQLite ou PostgreSQL). Ne pas le faire crée un point de défaillance unique plus risqué que GitHub ou GitLab.

Bonnes pratiques de commit

• Commits atomiques : un commit = une modification logique. Facilite les revert ciblés
• Messages descriptifs : format Conventional Commits (feat:, fix:, refactor:) pour un historique lisible
• Branches de fonctionnalité : ne jamais travailler directement sur main ou master
• Tags de version : tagguer chaque release (git tag v1.2.0) pour retrouver un état stable facilement
• Push fréquent : ne pas garder du travail en local plus de quelques heures sans pousser sur le distant

2. Miroirs et redondance des dépôts

Un seul dépôt distant est insuffisant. Si GitHub subit une panne ou suspend votre compte, vous devez pouvoir continuer à travailler immédiatement. La solution : configurer un miroir automatique vers un second service.

Miroir GitHub vers GitLab

GitLab propose une fonctionnalité native de miroir de dépôt (Settings > Repository > Mirroring repositories) qui synchronise automatiquement un dépôt GitHub toutes les heures. La configuration ne prend que quelques minutes et ne nécessite qu'un token d'accès GitHub en lecture.

Pour une synchronisation plus immédiate, utilisez un workflow GitHub Actions qui pousse vers GitLab à chaque push :

name: Mirror to GitLab
on: [push]
jobs:
  mirror:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with: { fetch-depth: 0 }
      - run: |
          git remote add gitlab https://oauth2:${{ secrets.GITLAB_TOKEN }}@gitlab.com/user/repo.git
          git push --mirror gitlab

Miroir local et archives

Complétez avec une sauvegarde locale périodique. La commande git clone --mirror crée une copie complète du dépôt (toutes les branches, tous les tags, les stashes). Archivez ensuite avec git bundle create repo.bundle --all pour un fichier transportable et restaurable. Planifiez cette opération via un cron job hebdomadaire vers un disque externe ou un NAS.

3. Sauvegardes de bases de données

Le code peut être reconstruit depuis Git, mais les données utilisateurs sont irréempçables. Les bases de données sont donc la partie la plus critique à sauvegarder, et souvent la plus négligée dans les petits projets.

mysqldump automatisé

Pour MySQL et MariaDB, mysqldump reste l'outil de base. Automatisez-le avec un cron job :

# Sauvegarde quotidienne à 2h du matin
0 2 * * * mysqldump -u user -pPASSWORD ma_base | gzip > /backups/ma_base_$(date +\%Y\%m\%d).sql.gz
# Nettoyer les sauvegardes de plus de 30 jours
0 3 * * * find /backups/ -name "*.sql.gz" -mtime +30 -delete

Poussez ensuite ces archives vers un stockage distant : AWS S3, Backblaze B2 (5 fois moins cher que S3) ou un second serveur via rsync. Ne jamais stocker les sauvegardes uniquement sur le même serveur que la base de données.

PostgreSQL avec pg_dump

Pour PostgreSQL, pg_dump et pg_dumpall remplissent le même rôle. Préférez le format --format=custom qui permet une restauration sélective par table et une meilleure compression que le SQL brut. Les services gérés comme Supabase, Neon ou Railway intègrent des sauvegardes automatiques avec point-in-time recovery (PITR) — une fonctionnalité qui permet de restaurer la base à n'importe quelle seconde des 7 derniers jours.

Fréquence et rétention

Type de projet	Fréquence	Rétention
Site vitrine / blog	Quotidienne	30 jours
Application avec utilisateurs	Toutes les 6h	90 jours
E-commerce / transactions	Toutes les heures	1 an + archives
Données sensibles (RGPD)	Temps réel (réplication)	Conformément au DPA

4. Gestion des secrets et fichiers .env

Les fichiers .env contiennent des informations critiques : clés API, mots de passe de bases de données, tokens OAuth, clés de chiffrement. Ils ne doivent jamais être commités dans Git, mais doivent tout de même être sauvegardés de façon sécurisée.

Ce qu'il ne faut jamais faire

• Committer un .env ou .env.local dans Git, même dans un dépôt privé
• Stocker des mots de passe en clair dans des fichiers de configuration versionnés
• Partager des secrets par email ou chat sans chiffrement
• Utiliser les mêmes credentials entre développement, staging et production

Les gestionnaires de secrets en production

Doppler et Infisical (open source, auto-hébergeable) permettent de centraliser tous les secrets de vos projets, de les synchroniser automatiquement dans vos environnements et de journaliser chaque accès. L'intégration avec les pipelines CI/CD (GitHub Actions, GitLab CI) se fait via des tokens de service à durée de vie limitée. HashiCorp Vault est la référence pour les environnements d'entreprise, avec rotation automatique des credentials et audit complet.

Pour les petites équipes, stocker les secrets de développement dans un gestionnaire de mots de passe partagé (1Password Teams, Bitwarden Organizations) est suffisant, à condition de définir clairement qui a accès à quoi.

La règle du .gitignore

Ajoutez systématiquement ces entrées à votre .gitignore :

.env
.env.local
.env.*.local
*.key
*.pem
secrets/
config/secrets.yaml

Configurez une clé de détection de secrets dans votre pipeline CI/CD (Gitleaks, git-secrets, TruffleHog) pour bloquer automatiquement tout commit qui contiendrait accidentellement des credentials.

5. Artefacts CI/CD et images Docker

Les pipelines CI/CD génèrent des artefacts précieux : binaires compilés, bundles JavaScript, images Docker, rapports de tests, documentation générée. Ces artefacts doivent être conservés pour permettre un rollback rapide sans recompilation.

Gestion des artefacts dans GitHub Actions

GitHub Actions permet de persister des artefacts avec l'action actions/upload-artifact. La rétention par défaut est de 90 jours. Pour les releases, utilisez GitHub Releases pour attacher des binaires à chaque tag de version : ils sont conservés indéfiniment et téléchargeables directement.

- uses: actions/upload-artifact@v4
  with:
    name: dist-${{ github.sha }}
    path: dist/
    retention-days: 30

Registre d'images Docker

Pour les applications conteneurisées, taggez chaque image avec le hash du commit Git (image:sha-abc1234) en plus du tag latest. Cela permet de revenir précisément à n'importe quelle version déployée. Utilisez GitHub Container Registry (GHCR), GitLab Container Registry ou Docker Hub avec une politique de rétention configurant la suppression des images de plus de 6 mois (sauf les tags de release).

6. Automatisation des sauvegardes serveur

Au-delà du code et des bases de données, un projet web en production comprend des fichiers serveur critiques : uploads utilisateurs, certificats SSL, configurations Nginx/Apache, crons, scripts de maintenance. Ces éléments doivent être inclus dans la stratégie de sauvegarde.

Restic : sauvegarde incrémentale chiffrée

Restic est l'outil de référence pour les sauvegardes serveur automatisées. Il crée des sauvegardes incrmentales chiffrées (AES-256) vers n'importe quel backend (local, S3, Backblaze B2, SFTP, rclone). Sa déduplication intelligente réduit considérablement l'espace de stockage. Un exemple de configuration pour un projet PHP :

# Initialiser le dépôt
restic -r s3:s3.amazonaws.com/mon-bucket init

# Sauvegarde quotidienne
restic -r s3:s3.amazonaws.com/mon-bucket backup \
  /var/www/html/uploads \
  /etc/nginx \
  /etc/letsencrypt

# Garder 7 quotidiennes, 4 hebdomadaires, 12 mensuelles
restic -r s3:s3.amazonaws.com/mon-bucket forget \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --prune

rsync pour les fichiers média

Pour synchroniser les fichiers uploads vers un second serveur ou un NAS, rsync reste l'outil le plus efficace grâce à sa synchronisation différentielle (seuls les fichiers modifiés sont transférés). Planifiez un rsync -avz --delete /var/www/html/uploads/ backup-server:/backups/uploads/ toutes les nuits via cron.

Pour les sites web qui gèrent également des projets clients (contrats, livrables, maquettes), il est utile de compléter ces sauvegardes techniques avec une solution dédiée aux documents. Ce guide sur les méthodes de sauvegarde de documents web détaille les approches complémentaires pour protéger l'ensemble des actifs d'un projet, y compris les fichiers non techniques.

Les services cloud de backup managé

Des solutions comme DigitalOcean Managed Backups, Hetzner Backup (inclus dans certains plans) ou Cloudflare R2 simplifient la gestion des sauvegardes en éliminant la gestion d'infrastructure. Le coût est généralement 20 % du prix du volume de stockage mensuel pour les Droplet Backups DigitalOcean.

7. Plan de reprise d'activité (PRA)

Avoir des sauvegardes sans plan de restauration, c'est comme avoir des extincteurs sans avoir formé les employés à s'en servir. Un plan de reprise d'activité (PRA) ou Disaster Recovery Plan (DRP) définit les procédures exactes à suivre en cas d'incident.

Les métriques clés d'un PRA

• RTO (Recovery Time Objective) : combien de temps maximum pour restaurer le service ? (ex : 4 heures pour un site e-commerce)
• RPO (Recovery Point Objective) : quelle perte de données maximale acceptable ? (ex : pas plus d'1 heure de transactions perdues)
• RLO (Recovery Level Objective) : à quel niveau de fonctionnalité minimum doit fonctionner le service après restauration ?

Le runbook de restauration

Rédigez un runbook clair et testé, accessible hors ligne (PDF, doc imprimé), détaillant pas à pas :

• Comment cloner le dépôt Git depuis le miroir de secours
• Comment restaurer la base de données depuis le dernier dump
• Comment reconfigurer les variables d'environnement depuis le gestionnaire de secrets
• Comment redéployer l'application sur un nouveau serveur ou un service cloud
• Comment vérifier que la restauration est complète et fonctionnelle

Tests de restauration périodiques

Planifiez des exercices de restauration mensuels sur un environnement de staging isolé. Chronométrez chaque étape, notez les blocages rencontrés et mettez à jour le runbook en conséquence. Une sauvegarde non testée est une sauvegarde dont l'intégrité est inconnue. Vérifiez les checksums des dumps SQL (md5sum ou sha256sum) et décompressez-les pour vérifier l'absence de corruption.

Enfin, documentez l'architecture de sauvegarde dans le README du projet : quels sont les services utilisés, quelle est la fréquence, où trouver les credentials de restauration. Cette documentation est aussi précieuse lors d'un changement d'équipe. Pour compléter ce guide, consultez notre article sur les compétences DevOps incontournables pour un développeur web en 2026.