Personne n’accepterait une comptabilité sans écritures datées, sans possibilité de savoir qui a modifié quoi et quand. Pourtant, une grande partie des sites professionnels vivent exactement comme cela : modifiés directement en ligne, sans trace, sans auteur, sans retour en arrière possible. Cet article explique ce qu’apporte un dépôt de code sans demander à personne de savoir programmer, et pose la question que les prestataires évitent : à qui appartient réellement le code de votre site.
Le problème que résout le versionnement
Quatre situations reviennent sans cesse, et un dépôt les fait disparaître.
- Personne ne sait ce qui a changé. Le site fonctionnait vendredi, plus lundi. Sans historique, l’enquête commence à zéro. Avec un historique, elle commence par une liste datée.
- Deux personnes s’écrasent mutuellement. Un développeur corrige un modèle de page pendant qu’un autre le modifie par l’éditeur en ligne. Le dernier qui enregistre gagne, l’autre perd son travail sans jamais le savoir.
- Une modification casse le site et personne ne sait revenir. On restaure alors une sauvegarde complète, ce qui écrase au passage les commandes et les articles publiés depuis.
- Le prestataire part avec la connaissance du site. C’est le point le plus coûteux, et le plus fréquent.
Le versionnement n’est pas un raffinement de développeur : c’est une assurance sur la continuité de votre outil de travail.
Git, GitHub, dépôt : le vocabulaire en cinq minutes
Le dépôt
Le classeur qui contient le code du site et l’intégralité de son histoire. On peut le dupliquer à volonté : chaque copie contient tout l’historique, ce qui en fait par construction un dispositif résistant.
La validation
Une modification datée, signée et commentée. C’est l’unité de base de l’historique, et sa qualité dépend entièrement du commentaire qui l’accompagne. « Corrections diverses » ne vaut rien ; « Corrige le calcul des frais de port pour la Corse » vaut de l’or six mois plus tard.
La branche
Une copie de travail parallèle où l’on prépare une évolution sans toucher au site en ligne. On peut en ouvrir dix, les abandonner, y revenir. Le site public, lui, ne bouge pas.
La demande de fusion
Le moment où l’on propose d’intégrer une évolution. C’est là que se place la relecture : une deuxième paire d’yeux, des tests automatiques, une validation explicite. Rien n’atteint le site sans passer par cette porte.
Git et GitHub
Git est l’outil qui gère l’histoire, sur votre machine. GitHub est l’endroit où cette histoire est hébergée, partagée et discutée. On peut utiliser Git sans GitHub, et remplacer GitHub par GitLab, Bitbucket ou un serveur interne sans rien changer au reste.
Ce que cela change au quotidien
La différence se mesure en temps, et elle est spectaculaire. Retrouver l’origine d’un défaut sur un site sans historique, c’est une demi-journée d’enquête et d’hypothèses. Avec un historique propre, c’est trois minutes :
git log --oneline -10 -- wp-content/themes/mon-theme/
git show 4f2a91c
git revert 4f2a91cLa dernière commande mérite une explication, parce qu’elle est le cœur du sujet pour un dirigeant. git revert n’efface rien et ne remonte pas le temps : elle ajoute une nouvelle validation qui annule précisément les effets d’une modification passée, en laissant intact tout ce qui a été fait depuis. C’est l’exact opposé de la restauration de sauvegarde, qui ramène le site entier en arrière et sacrifie les données récentes.
Quand on ignore quelle modification a introduit le défaut, la recherche par dichotomie automatique tranche la question en quelques essais, même sur plusieurs centaines de validations :
git bisect start
git bisect bad # la version actuelle est cassée
git bisect good v1.4.0 # cette version fonctionnaitCette mécanique rend possible ce qu’aucune sauvegarde ne permet : annuler une décision sans annuler la semaine.
Du dépôt au site en ligne : le déploiement automatisé
La chaîne est toujours la même : une modification validée déclenche des vérifications automatiques, puis une mise en ligne sur la préproduction, puis, après validation humaine, sur le site réel. Deux garanties en découlent, la reproductibilité et la traçabilité : chaque mise en ligne est identique à la précédente et laisse une trace consultable.
Sur GitHub, cette chaîne s’écrit dans un fichier déposé dans le dépôt lui-même. Voici le squelette d’un déploiement de thème WordPress, volontairement minimal :
name: Déploiement du thème
on:
push:
branches:
- main
jobs:
deployer:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- name: Contrôle de syntaxe PHP
run: find wp-content/themes/mon-theme -name "*.php" -print0 | xargs -0 -n1 php -l
- name: Envoi vers le serveur
run: rsync -az --delete wp-content/themes/mon-theme/ \
deploy@$SERVEUR:/var/www/site/wp-content/themes/mon-theme/L’ordre des étapes n’est pas décoratif : le contrôle de syntaxe passe avant l’envoi, ce qui suffit à empêcher la mise en ligne d’un fichier PHP invalide, cause d’un bon tiers des écrans blancs. Côté coût, l’exécution est gratuite pour les dépôts publics, et un compte gratuit dispose de 2 000 minutes par mois pour ses dépôts privés, 3 000 pour un compte Pro ou une équipe. Un déploiement de thème consomme une à deux minutes : la limite ne sera jamais un sujet pour un site vitrine.
Un point d’honnêteté : tout ne rentre pas dans le dépôt. La base de données et les fichiers envoyés par le client vivent ailleurs et suivent un autre cycle. C’est précisément pourquoi un dépôt ne dispense jamais d’une politique de sauvegarde testée.
Et si mon site est sous WordPress ?
La question est légitime, car WordPress a été conçu pour être modifié depuis son administration. Le périmètre réaliste est le suivant :
| Dans le dépôt | Hors du dépôt |
|---|---|
| Le thème ou le thème enfant | La base de données |
| Les extensions développées sur mesure | Le dossier des envois |
| La liste des extensions et leurs versions | Les fichiers de configuration contenant des mots de passe |
| Les scripts de déploiement et la chaîne d’intégration | Les caches et fichiers temporaires |
Le fichier d’exclusion mérite d’être écrit une bonne fois, en n’incluant que ce qui vous appartient réellement :
/*
!/wp-content/
/wp-content/*
!/wp-content/themes/
/wp-content/themes/*
!/wp-content/themes/mon-theme/
!/wp-content/plugins/mon-extension-maison/
wp-config.php
*.logL’organisation qui fonctionne tient en trois pièces : le dépôt pour le code, une préproduction pour les tests, des sauvegardes pour les données. C’est aussi ce trio qui permet d’annuler une mise à jour qui a cassé le site sans drame, et qui fait disparaître la peur des conséquences d’une maintenance négligée.
La question qui fâche : à qui appartient le code
Voici la partie que l’on ne vous dira pas spontanément. Un dépôt hébergé sur le compte de votre prestataire, avec vous en simple invité, ne vous protège de rien : le jour où la relation s’arrête, l’accès s’arrête aussi. Un dépôt hébergé sur votre compte d’organisation, avec le prestataire invité comme collaborateur, change complètement le rapport de force. C’est la même différence qu’entre un domaine déposé à votre nom et un domaine déposé au nom de l’agence.
Quatre exigences à poser par écrit, avant le début du projet :
- Le dépôt appartient à votre organisation, le prestataire y est invité.
- La procédure de déploiement est documentée dans le dépôt, en clair, et reproductible par un tiers.
- Aucun secret n’est stocké dans le code : mots de passe et clés vivent dans un coffre, référencés par des variables.
- Le projet n’introduit aucune dépendance à un outil fermé que vous ne pourriez pas reprendre.
Un prestataire sérieux acceptera ces quatre points sans discuter, parce qu’ils ne lui coûtent rien. Une réticence sur le premier vous en apprendra beaucoup, et rejoint les questions à poser avant de signer que nous listons dans notre guide sur comment choisir son agence web. C’est aussi ce qui permet de garder la main sur son site en changeant de prestataire.
Notre position : faut-il tout versionner ?
Non, et le prétendre serait malhonnête. Pour un site vitrine simple, géré uniquement par son propriétaire via l’administration, sans une ligne de code sur mesure, une politique de sauvegarde bien faite couvre le besoin. Ajouter un dépôt n’apporterait qu’une contrainte de plus.
Trois critères font basculer la décision, et un seul suffit : il existe du code sur mesure, thème ou extension maison ; plusieurs personnes interviennent sur le site ; le site porte des transactions ou évolue chaque mois. Dans ces cas, l’absence de dépôt n’est plus une simplification, c’est un risque que quelqu’un finira par payer.
Notre pratique est simple et sans exception : tout projet sur mesure part avec un dépôt ouvert au nom du client dès le premier jour, une préproduction et un déploiement automatisé. Quand nous reprenons un site existant, la mise sous dépôt est le premier chantier, avant même les corrections, parce qu’elle rend tout le reste réversible. C’est ce que couvre notre offre de reprise et remise en état d’un site existant. Pour aller plus loin sur les outils de référence, le livre Pro Git et la documentation GitHub existent tous deux en français.
Questions fréquentes
Dois-je apprendre Git en tant que dirigeant ?
Non. Vous devez seulement exiger que votre site en bénéficie, que le dépôt soit ouvert à votre nom et que vous en soyez propriétaire. Savoir lire une liste de modifications datées suffit largement.
Un dépôt remplace-t-il les sauvegardes ?
Non, et c’est la confusion la plus fréquente. Le dépôt protège le code, les sauvegardes protègent les données. Un dépôt impeccable ne vous rendra jamais les commandes ni les photos perdues.
GitHub convient-il à un projet confidentiel ?
Oui, les dépôts privés existent sur tous les comptes, y compris gratuits. La confidentialité dépend surtout de la gestion des accès et du fait de ne jamais y stocker de mots de passe en clair.
Peut-on mettre en place un dépôt sur un site existant ?
Oui. C’est même souvent le premier chantier d’une reprise de site : on récupère le code en place, on l’initialise dans un dépôt, et l’on obtient enfin un point de comparaison stable.
Un site sans historique est un site dont personne ne peut garantir l’avenir. Le versionnement ne le rend ni plus beau ni plus rapide : il le rend réparable, transmissible et évolutif. Si votre site est déjà en production, commencez par la question la plus simple : demandez où se trouve son code, et à quel nom.
À lire aussi : Astro ou WordPress : quel socle pour votre prochain site
Parler d’un projet versionnéReprendre en main un site existant
