Quand un projet web tourne mal, le diagnostic commence presque toujours au même endroit : le code. Où est-il ? Qui l'a modifié, quand, pourquoi ? Peut-on revenir en arrière ? Chez HWS, la réponse à ces questions s'appelle GitHub. Tous nos projets y sont versionnés, relus et déployés. Cet article explique ce que fait cet outil, comment notre agence s'en sert, et pourquoi c'est votre meilleure assurance-vie numérique — surtout si vous avez déjà connu un projet qui a mal fini.
À quoi sert GitHub ?
GitHub est la plateforme de référence pour héberger du code et organiser le travail des développeurs. Elle repose sur Git, un système de « versioning » : chaque modification du code est enregistrée, datée, signée et réversible.
Pour un dirigeant non technique, trois images suffisent :
- Un historique complet. Comme un livre de comptes, chaque changement est tracé. On sait qui a fait quoi, quand, et pourquoi.
- Une machine à remonter le temps. Une mise à jour pose problème ? On revient à la version d'avant en quelques minutes.
- Un lieu de travail commun. Plusieurs développeurs avancent en parallèle sans écraser le travail des autres, et chaque contribution est relue avant d'être intégrée.
Le point essentiel pour vous : le dépôt GitHub, c'est le patrimoine de votre projet. Exigez d'en être propriétaire ou d'y avoir accès. Un prestataire qui refuse doit vous alerter.
Comment nous l'utilisons chez HWS
GitHub structure trois pratiques quotidiennes de l'agence.
Tout est versionné, sans exception
Chaque projet HWS vit dans un dépôt Git dès la première heure. Sites, applications, scripts, configurations : tout. Chaque modification est décrite en une phrase claire. Six mois plus tard, on peut retrouver pourquoi telle décision a été prise — c'est de la mémoire de projet, et elle vous appartient autant qu'à nous.
La revue de code systématique
Aucun code ne rejoint la version principale d'un projet sans avoir été relu par un autre développeur que son auteur. GitHub organise ce rituel : l'auteur propose ses modifications, un relecteur les examine ligne par ligne, commente, demande des ajustements, puis valide. C'est un garde-fou contre les bugs, mais aussi contre la dépendance à une seule personne : au moins deux développeurs comprennent chaque partie du projet. Avec l'arrivée d'outils comme Claude dans nos workflows, cette relecture humaine est devenue encore plus importante, pas moins.
Les déploiements automatisés avec GitHub Actions
Mettre en ligne une nouvelle version « à la main » est la première source d'incidents en production. Nous l'avons éliminée. Avec GitHub Actions, chaque modification validée déclenche automatiquement une série de vérifications — les tests — puis, si tout est vert, le déploiement. C'est ce qu'on appelle le CI/CD. Concrètement pour vous : des mises en production fréquentes, courtes et sans sueurs froides, au lieu de grosses mises à jour risquées tous les trimestres. Et si une vérification échoue, la mise en ligne est bloquée avant que vos utilisateurs ne voient quoi que ce soit.
Pourquoi ce choix (et ses limites)
Pourquoi GitHub plutôt qu'un concurrent ? D'abord parce que c'est le standard du métier : tout développeur le connaît, ce qui compte le jour où votre projet change de mains. Ensuite parce que son écosystème — revue de code, automatisations, gestion des tickets — couvre tout notre cycle de travail dans un seul outil.
Les limites, honnêtement :
- GitHub n'est pas une sauvegarde de votre site en production. Il conserve le code, pas forcément vos données ni vos contenus. La stratégie de sauvegarde est un sujet distinct, que nous traitons dans nos contrats de maintenance.
- L'outil ne crée pas la discipline. Un dépôt mal tenu — messages vides, pas de relecture — donne une fausse impression de sécurité. C'est la méthode qui fait la valeur, GitHub ne fait que la rendre possible.
- C'est un service américain centralisé. Pour certains contextes sensibles, la question de l'hébergement du code mérite d'être posée. Elle a des réponses, mais il faut la poser.
Un exemple concret : PO-Scorad
PO-Scorad est une application médicale native que HWS a reprise pour la remettre à jour. C'est le scénario classique de la reprise de projet web : une application existante, un historique de développement à reconstituer, et l'obligation de ne rien casser — dans le médical, l'à-peu-près n'existe pas.
La restauration d'un dépôt Git propre a compté dans la réussite du projet. Retrouver un historique lisible, isoler chaque modification, pouvoir revenir en arrière à tout moment : c'est ce qui a permis de moderniser l'application par étapes maîtrisées plutôt qu'en pariant sur une réécriture totale. Sans cette base, le même projet aurait coûté plus cher et fait courir plus de risques.
Ce qu'il faut retenir
GitHub n'est pas un gadget de développeur. C'est l'infrastructure qui rend votre projet traçable, réversible et transmissible. Trois questions à poser à votre prestataire actuel : le code est-il versionné ? Est-il relu ? Ai-je accès au dépôt ? Si une réponse est non, il y a un sujet.
Et si vous héritez d'un projet dont personne ne retrouve le code source, ce n'est pas une fatalité : c'est exactement le genre de situation que nous démêlons. Parlez-nous de votre projet, on commencera par regarder le dépôt — ou par en reconstruire un.
