Le problème du SFTP et des déploiements manuels
Déployer en glissant des fichiers par SFTP est la meilleure façon d'obtenir des sites à moitié cassés : un fichier est oublié, composer n'est pas exécuté, une migration est oubliée, et le cache continue de servir l'ancien bundle. Il n'y a aucune trace de ce qui a été mis en ligne, ni de moyen propre de le reproduire. GitHub Deploy remplace cela par un pipeline défini rattaché à votre dépôt, si bien qu'une release est le résultat déterministe d'un commit et d'un ensemble fixe d'étapes — identique à chaque fois, par n'importe qui dans l'équipe.
Vos étapes de build, exécutées de façon cohérente
Un vrai déploiement, c'est plus que copier des fichiers : les dépendances doivent être installées, les assets compilés, et les migrations de base de données appliquées dans le bon ordre. Vous définissez ces étapes une seule fois — par exemple composer install, un build npm ou d'assets, et une commande de migration — et elles s'exécutent à chaque déploiement sur le commit exact mis en ligne. Cela élimine toute une catégorie de bugs où la production se comporte différemment parce que quelqu'un a exécuté les étapes dans un ordre différent ou en a sauté une sous la pression.
Déploiements manuels et auto-déploiement par webhook
Chaque équipe a ses propres préférences de déclenchement. Une équipe prudente garde les déploiements manuels, en cliquant sur déployer dans le panneau après revue, si bien qu'une release est un acte délibéré. Une équipe qui avance vite active le webhook afin que chaque push sur la branche de production soit mis en ligne automatiquement, transformant git push en déploiement. Les deux exécutent le même pipeline ; seul ce qui déclenche l'action diffère, et vous pouvez commencer en manuel puis activer le webhook une fois que vous faites confiance au flux.
Dépôts privés et tokens sécurisés
La majorité du code réel se trouve dans des dépôts privés, si bien que la plateforme s'authentifie avec un token que vous fournissez plutôt que d'exiger que le code soit public. Le token est stocké comme un secret et utilisé uniquement pour cloner au moment du déploiement ; il n'apparaît jamais dans les logs ni dans l'interface une fois enregistré, et comme il est indépendant de votre code, vous pouvez le régénérer ou le révoquer séparément. Les livraisons de webhook sont vérifiées avec un secret signé afin qu'un POST aléatoire ne puisse pas déclencher une release.
La purge automatique comble la dernière lacune
Le bug post-déploiement le plus courant est une nouvelle release cachée derrière un cache edge obsolète — un nouveau CSS ou JS est mis en ligne, mais les visiteurs chargent toujours l'ancien bundle mis en cache. GitHub Deploy purge le cache edge dans le cadre de la release, si bien que le déploiement n'est considéré terminé que lorsque le cache reflète les nouveaux fichiers. Cela supprime l'étape de purge manuelle que l'on oublie toujours, et garantit que ce que vous avez mis en ligne est bien ce que reçoivent les visiteurs.
Une livraison reproductible pour les équipes et les agences
Quand chaque projet se déploie de la même façon, l'onboarding et la passation cessent d'être une connaissance tribale. Le statut de déploiement, l'heure du dernier déploiement, et les étapes configurées sont visibles dans le panneau, si bien que n'importe qui peut voir si le dernier push est arrivé en production et ce qui s'est exécuté. Pour les agences, cela signifie un modèle de livraison standard sur tous les projets clients, où confier un site à un autre développeur ne nécessite pas de rétro-ingénierier un rituel de déploiement maison et non documenté.
Comment déployer, étape par étape
Connecter le dépôt et la branche
Dans le panneau, ouvrez votre application, allez dans GitHub Deploy, et saisissez l'URL du dépôt ainsi que la branche depuis laquelle vous déployez — typiquement main ou production. La branche que vous choisissez est celle qui passe en production, si bien que les branches de fonctionnalité ne sont jamais mises en ligne par accident.
Autoriser un dépôt privé
Si le dépôt est privé, ajoutez un personal access token ou un deploy token afin que la plateforme puisse le cloner. Le token est stocké comme un secret, utilisé uniquement pour récupérer le code au moment du déploiement, et peut être révoqué ou régénéré sans toucher à votre application.
Définir les étapes de build et de migration
Configurez les commandes qui transforment un checkout en release fonctionnelle — pour une application PHP, c'est généralement composer install --no-dev, un build d'assets front-end, et une migration de base de données. Ces étapes sont sauvegardées avec l'application afin que chaque déploiement exécute un pipeline identique, et non ce que quelqu'un se souvient d'avoir tapé.
Choisir le déploiement manuel ou l'auto-déploiement par webhook
Déployez à la demande avec un bouton dans le panneau, ou activez le webhook afin qu'un push sur la branche connectée déclenche automatiquement le déploiement. Le webhook utilise un secret signé, si bien que seuls de vrais push provenant de votre dépôt peuvent démarrer une release.
Livrer, purger et confirmer
Au déploiement, la plateforme récupère la branche, exécute vos étapes, et active la nouvelle release ; le cache edge des assets modifiés est purgé automatiquement afin que les visiteurs ne reçoivent pas de fichiers obsolètes. Le panneau affiche le statut de déploiement et l'heure du dernier déploiement pour que vous puissiez confirmer que la release est bien en ligne.
Exemples de scénarios
Un push sur main déclenche composer install, un build d'assets, et des migrations, puis la release est mise en ligne et le cache edge est purgé automatiquement.
Une agence connecte un dépôt GitHub privé avec un token de déploiement à portée limitée, gardant le code fermé tandis que la plateforme continue de le récupérer et de le déployer.
Une équipe garde l'auto-déploiement désactivé et clique sur déployer dans le panneau après revue de code, de sorte que chaque release en production est une action délibérée et journalisée.
Questions fréquentes
GitHub Deploy construit-il une image Docker, ou déploie-t-il du code source ?
Il déploie le code source de l'application sur le runtime de la plateforme — il récupère votre branche et exécute vos étapes de build et de migration directement sur le code. C'est le choix naturel pour PHP et les applications basées sur un framework. Si vous voulez spécifiquement construire et exécuter une image de container, utilisez plutôt Container Apps avec une image préconstruite ou Docker Compose Instant Deploy.
Que se passe-t-il exactement lors d'un push webhook ?
Un push sur la branche connectée envoie un webhook signé à la plateforme, qui vérifie la signature, clone ou récupère ce commit, exécute vos étapes de build et de migration définies, active la nouvelle release, et purge le cache edge. Le panneau met alors à jour le statut de déploiement et l'heure du dernier déploiement afin que vous puissiez confirmer que tout est bien arrivé.
Comment mon access token est-il protégé ?
Le token est stocké comme un secret et utilisé uniquement pour cloner le dépôt au moment du déploiement. Il n'est pas réaffiché après l'enregistrement et n'apparaît pas dans les logs de build, et comme il vit séparément de votre code, vous pouvez le régénérer ou le révoquer sur GitHub sans rien changer dans l'application.
Puis-je revenir en arrière si un déploiement tourne mal ?
Comme les déploiements sont rattachés à des commits et des étapes définies, revenir en arrière consiste simplement à déployer un commit dont vous savez qu'il fonctionne — vous pointez le déploiement sur le commit précédent qui fonctionnait ou vous revert sur la branche et laissez le pipeline le mettre en ligne. Garder les déploiements reproductibles est précisément ce qui rend un retour en arrière fiable plutôt que précipité.
Quelle branche passe en production, et puis-je déployer depuis plusieurs branches ?
Vous choisissez la branche à déployer, typiquement main ou une branche de production dédiée, et seule cette branche est mise en ligne — les push sur les branches de fonctionnalité ne déclenchent pas de déploiement. Cela garde le travail en cours hors de la production tout en vous permettant de déployer dès que vous mergez vers la branche de release.
Est-ce que ça fonctionne avec GitLab ou d'autres hébergeurs Git, ou seulement GitHub ?
Le workflow repose sur une URL de dépôt Git, une branche, et un token, il n'est donc pas limité à GitHub spécifiquement — tout dépôt que vous pouvez atteindre avec une URL et un access token entre dans le même modèle. GitHub est le cas d'usage le plus courant, d'où son nom, mais la mécanique reste du Git standard.