Vendredi 18 h 30 : correction urgente en FTP, fichier oublié, cache opcode pas vidé, retour arrière impossible parce que personne n'a tagué la version précédente. L'équipe compte deux développeurs et un fondateur — pas d'ingénieur plateforme dédié, pas de budget infrastructure lourde. Pourtant un pipeline de trente lignes aurait déployé la même correction en deux minutes, avec historique.
Ce scénario se répète dès qu'un déploiement manuel devient la norme sous pression. CI/CD pour une petite équipe n'est pas un catalogue d'outils DevOps. C'est automatiser les gestes que vous refaites déjà — et arrêter de confier la production au clic manuel fatigué.
La bonne ambition n'est pas « faire comme les géants du web ». C'est ne plus déployer la production depuis le portable du canapé — sans permission explicite du vendredi soir.
Commencez petit : un workflow qui lint, teste et déploie en staging suffit souvent la première semaine. Ajoutez la production manuelle seulement lorsque le staging a prouvé sa fiabilité — pas l'inverse.
Le pipeline minimum viable
1. Déclencheur — push sur main ou merge de pull request.
2. Install + lint + test — ce qui casse souvent en production (syntaxe, tests paiement, migrations dry-run).
3. Build — artefact versionné (archive, image Docker, assets compilés).
4. Deploy staging — automatique ; smoke test curl ou Playwright léger.
5. Deploy prod — manuel approuvé ou tag v* ; notification Slack ou email.
| Étape | Outil courant | Skip si… |
|---|---|---|
| Lint | ESLint, PHPStan | Jamais — coût quasi nul |
| Tests | PHPUnit, Jest | Prototype jetable uniquement |
| Build | npm run build | PHP pur sans assets |
| Deploy | SSH + rsync, Clever Cloud, Forge | Mutualisé sans SSH |
Automatisez d'abord ce qui a déjà causé une panne. Le reste attend.
Hébergement et mode de déploiement
VPS + SSH — script idempotent, releases dans /var/www/releases/ plus lien symbolique current, retour arrière = repointage du lien.
PaaS (Clever Cloud, Platform.sh, Render) — déploiement git push ; CI appelle CLI ou webhook.
Mutualisé — CI limitée ; parfois FTP seulement. Envisagez migration vers VPS ou PaaS dès que déploiement plus de deux fois par semaine.
Le mode de déploiement conditionne le pipeline : un PaaS comme Clever Cloud accepte un push Git depuis la CI ; un VPS demande SSH et un script idempotent. Choisir l'hébergement et le pipeline ensemble évite de construire quarante jobs pour un mutualisé qui n'accepte que le FTP.
Comparez les hébergeurs adaptés au déploiement Git dans notre comparateur.
Exemple de workflow minimal
Un fichier .github/workflows/deploy.yml de trente lignes suffit souvent : déclencheur sur main, installation des dépendances, lint, tests, build, déploiement SSH vers la préproduction. La production reste déclenchée manuellement via workflow_dispatch ou tag. Documentez les variables secrètes dans le README interne — hôte SSH, clé privée, chemin de déploiement — pour que la procédure survive au départ d'un développeur.
Erreurs des petites équipes
Un pipeline de vingt-cinq minutes finit contourné : personne n'attend, le FTP revient. Les secrets en clair dans un .env commité « par oubli » restent la cause la plus fréquente de compromission. La production automatique sans préproduction transforme chaque fusion en roulette russe. L'absence de retour arrière documenté provoque la panique au premier échec. Enfin, sans notifications, le déploiement cassé est découvert par le client — jamais par l'équipe.
Retour arrière sans drame
Tags git sur chaque release production. Artefacts conservés sur N versions. Lien symbolique ou retour arrière PaaS en une commande. Base : migrations réversibles ou sauvegarde pre-deploy — voir stratégie sauvegarde.
Le sommet : l'automatisation qui ne s'exécute jamais
Mieux vaut trois étapes toujours vertes qu'une cathédrale contournée.
Décider et avancer sans angle mort
Commencez par lister les trois dernières pannes liées au déploiement — c'est votre backlog prioritaire. Rédigez ensuite un workflow de cinq étapes maximum qui couvre ces risques précis. Branchez les secrets du forge et le déploiement automatique en préproduction. Exigez un test de fumée avant toute mise en production. Documentez la procédure de retour arrière sur une page accessible à toute l'équipe. Si vous containerisez l'artefact, consultez aussi notre guide Docker pour débuter.
Questions fréquentes
Quel outil CI pour deux développeurs ?
GitHub Actions ou GitLab CI suffisent largement. Évitez Jenkins auto-hébergé tant que l'administration coûte plus que le gain — deux développeurs n'ont pas le temps de maintenir une forge CI en parallèle du produit.
Que tester avant deploy ?
Le linter, les tests critiques et un build propre forment le socle. Ajoutez un test HTTP en préproduction si vous en disposez — pas besoin de couverture exhaustive pour commencer.
Deploy auto prod dès merge ?
Trop risqué sans préproduction. Déployez automatiquement la préproduction ; gardez la production manuelle ou déclenchée par tag après validation.
Où stocker secrets CI ?
Dans les secrets chiffrés du forge, jamais dans le dépôt. Prévoyez une rotation lors des départs d'équipe.
CI/CD pour une petite équipe, ce n'est pas « faire comme Google ». C'est ne plus déployer la prod depuis le laptop du canapé — sans permission explicite du vendredi soir.