git push production main — et trois minutes plus tard le site affiche une erreur 500 parce qu'une migration SQL a été oubliée. L'équipe savait qu'il fallait « faire attention ». Le rituel n'était pas mauvais pour un blog perso ; il l'était pour une boutique qui encaisse.
Git push deploy : le dépôt distant sur le serveur exécute un hook qui tire le code et recharge PHP-FPM. CI/CD : chaque push passe par une pipeline qui build, teste, artefacte, puis déploie — ou refuse. La question n'est pas la technologie à la mode ; c'est quel coût d'erreur votre organisation accepte sans filet.
Deux rituels, deux niveaux de filet
| Dimension | Git push → serveur | CI/CD (Actions, GitLab, etc.) |
|---|---|---|
| Tests avant prod | Manuel (souvent sauté) | Automatisés, bloquants |
| Reproductibilité | « Ça marche sur ma machine » | Artefact identique par commit |
| Rollback | Git revert + redeploy manuel | Tag/release + redeploy pipeline |
| Audit | Logs SSH | Historique pipeline + approbations |
| Secrets | Risque clé sur serveur | Vault CI, OIDC cloud |
| Temps setup | Heures | Jours puis minutes/deploy |
La simplicité du push direct se paie en incidents que personne n'a chiffrés avant le premier vendredi soir.
Quand le push direct tient encore la route
Projet solo, faible criticité. Blog statique, portfolio : build local, rsync ou push hook, backup avant deploy.
Environnement staging identique. Push d'abord sur staging, validation humaine, puis fast-forward prod — discipline manuelle stricte.
Équipe colocalisée, déploiements rares. Mise à jour trimestrielle, fenêtre maintenance annoncée.
Conditions non négociables même en « simple » :
- Branche
mainprotégée - Tag ou commit hash noté en cas de rollback
- Migrations base versionnées et testées sur copie
Quand CI/CD devient la norme minimale
E-commerce, SaaS, données sensibles. Tests unitaires + intégration + smoke test post-deploy.
Équipe > 2 développeurs. Revue de code (PR) + pipeline verte avant merge.
Conformité. Traçabilité qui a déployé quoi, quand — ISO, SOC2, clients enterprise.
Multi-environnements. dev → staging → prod avec promotions contrôlées.
Pipeline minimale réaliste :
- Lint + tests sur PR
- Build artefact (container ou tarball)
- Deploy staging auto
- Deploy prod manuel ou auto après tag
Hébergeurs comme Clever Cloud ou Plateformes PaaS intègrent souvent le déploiement Git natif avec build remote — ce n'est pas du push nu vers /var/www.
Erreurs fréquentes des deux camps
Push direct : deploy le vendredi 18 h, migrations non réversibles, permissions 777 « temporaires ».
CI/CD : pipeline longue non optimisée, flakiness ignorée, secrets en variables plain text, deploy prod sans staging.
Le sommet : le hook post-receive n'est pas une stratégie
Décider et avancer sans angle mort
- Estimez coût horaire d'une panne prod (CA, SLA, réputation).
- Si > faible : pipeline minimale sous une semaine (GitHub Actions + SSH deploy ou webhook PaaS).
- Gardez push direct seulement pour envs jetables avec backup.
- Documentez rollback en moins de 15 minutes — testé.
Comparez hébergeurs avec déploiement Git intégré dans annuaire. Voir aussi Docker Compose ou Kubernetes pour la suite architecture.
Questions fréquentes
Le Git push direct est-il acceptable en production ?
Parfois pour vitrine solo. Dès qu'une erreur coûte cher, l'absence de tests automatisés est un risque inacceptable.
CI/CD ne ralentit-il pas les petites équipes ?
Pipeline minimale : 2–5 min, souvent moins qu'un rollback manuel après bug prod.
Où stocker les secrets de deploy ?
Variables CI chiffrées, vault, clés deploy-only — jamais dans le dépôt ni root SSH généralisé.
Peut-on combiner les deux ?
Oui : push déclenche CI qui deploy si vert. Évitez push nu vers prod sans gate.
Avant le prochain deploy, une question : si ce commit casse prod, combien de minutes pour revenir en arrière — et qui sait le faire ? Si la réponse est floue, le rituel n'est pas encore au niveau du risque.