Git, c’est une habitude de développeur. Mais c’est aussi une assurance pour le client, à condition de comprendre ce qu’elle protège. Voilà, en termes simples, ce que vous devez savoir sur Git quand vous payez quelqu’un pour développer un site.
Ce que Git fait exactement
Git, c’est un système qui enregistre l’historique complet d’un projet de développement. Chaque modification du code est sauvegardée, datée, identifiée par son auteur. On peut revenir à n’importe quel point dans le passé. On peut comparer deux versions. On peut travailler à plusieurs sur le même code sans s’écraser.
Pour le développeur, c’est indispensable. Pour le client, c’est plusieurs choses.
C’est une trace de qui a fait quoi, et quand. Si un bug apparaît trois mois après la mise en ligne, on peut retrouver ce qui a été modifié récemment.
C’est une sauvegarde du code. Si le serveur saute, le code est toujours sur GitHub, GitLab, Bitbucket, ou ailleurs.
C’est une garantie de continuité. Si vous changez de prestataire, le nouveau peut reprendre le projet là où l’autre l’a laissé, en lisant l’historique.
Le drapeau rouge ultime
Si votre prestataire vous dit « on n’utilise pas Git, on travaille directement sur le serveur », fuyez.
C’est rare aujourd’hui, mais ça arrive encore. Surtout chez les freelances débutants ou les agences à très bas tarif. Travailler sans Git, c’est aucune trace des modifications. Si quelque chose se casse, on ne sait pas pourquoi.
Aucune sauvegarde du code. Si le serveur crashe, on perd tout.
Aucune façon de travailler à plusieurs proprement. Deux développeurs qui modifient le même fichier en même temps : conflits ingérables.
Aucune façon de revenir en arrière. Si une mise à jour casse le site, c’est dramatique de retrouver une version stable.
C’est l’équivalent de bricoler un moteur de voiture sans schéma, sans manuel, et sans pouvoir revenir en arrière. Au mieux, ça marche. Au pire, c’est la catastrophe.
Les questions à poser sur Git
Sans devenir expert, vous pouvez vérifier ces points avec votre prestataire.
Sur quelle plateforme est hébergé le code ? GitHub, GitLab, Bitbucket sont les plus courants. Pour un projet client, je travaille presque toujours sur un dépôt privé GitHub, dont je donne accès au client.
Aurai-je accès au dépôt ? La réponse doit être oui. Le code est à vous, vous avez le droit d’y accéder. Si on vous le refuse, c’est un drapeau rouge.
Combien de temps après le projet aurai-je toujours accès ? Idéalement, pour toujours. Au minimum, le temps qu’on transfère la propriété du dépôt sur votre compte ou sur celui de votre nouvelle équipe.
Comment se passe une mise à jour en production ? Y a-t-il un processus de déploiement automatisé (CI/CD) ? Ou est-ce que le développeur uploade manuellement à chaque fois ?
Ce que je mets en place pour mes clients
Sur tout projet de plus de 4 000 €, je mets systématiquement en place quatre choses.
Un dépôt Git privé sur GitHub. Le client en est propriétaire à la fin du projet (transfert d’organisation).
Au moins deux branches : main (le code en production) et develop (le code en cours de modification). Les modifications passent d’abord par develop, sont testées, puis poussées en production via une pull request validée.
Un environnement de préproduction. Une version test du site, accessible uniquement avec un mot de passe, où on déploie automatiquement les modifications avant la production. Le client peut tester avant que ses visiteurs ne voient.
Un déploiement automatisé. Chaque fois qu’on pousse sur la branche main, le site de production se met à jour automatiquement. Pas de transfert FTP manuel, pas de risque d’oubli.
Cette infrastructure ajoute environ 600 € au projet initial. Elle économise des centaines d’heures sur la durée de vie du site.
Pour un client : comment naviguer dans un dépôt Git
Si votre prestataire vous donne accès à un dépôt GitHub, vous pouvez y voir des choses utiles même sans être technique.
L’onglet Commits montre l’historique des modifications. Chaque commit a un message qui explique ce qui a été changé.
L’onglet Issues sert à tracer les bugs et les demandes. Si vous voyez 30 issues ouvertes, ça vous dit quelque chose sur l’état du projet.
L’onglet Pull requests montre les modifications en cours de validation. Vous pouvez les commenter pour donner votre avis.
Vous n’avez pas besoin de comprendre le code pour utiliser ces vues. Vous voyez l’activité, la fréquence des modifications, le niveau d’organisation.
Le piège du code uniquement sur le serveur
J’ai repris en 2025 un site dont le code n’était que sur le serveur de production. Pas de Git, pas de sauvegarde versionnée. Ancien prestataire injoignable.
Pour ressaisir le code, j’ai dû le télécharger depuis le serveur (le client avait les accès FTP). C’était trois ans de modifications accumulées sans documentation. J’ai mis quatre jours à comprendre comment était construit le site, là où une journée aurait suffi avec un Git propre.
Coût supplémentaire pour le client : environ 1 200 €. Tout ça parce que l’ancien prestataire n’avait pas mis en place Git.
L’investissement minimum
Pour un projet à 5 000 € ou plus, exiger Git est un minimum. Si votre prestataire ne l’utilise pas naturellement, soit il faut qu’il s’y mette, soit il faut changer de prestataire.
Pour un projet à 2 000 €, c’est plus discutable. Sur un site simple, le coût de mise en place de Git peut représenter 10 à 15 % du projet. À voir au cas par cas, mais je le recommande quand même : ça vous protège.
Git n’est pas une option pour un projet sérieux. C’est l’infrastructure de base. Tout dev qui prétend être pro le maîtrise et l’utilise par défaut.