Ton projet solo n'a (probablement) pas besoin d'une CI/CD

En bref

Tu bosses seul sur un projet perso et tu passes plus de temps à configurer GitHub Actions ou GitLab CI/CD qu’à coder ? Un simple Makefile couplé aux Git Hooks couvre la majorité de tes besoins, sans YAML, sans runner, sans attente.

Le syndrome du « vrai développeur »

On a tous été là. Tu démarres un projet perso, et avant même d’écrire ta première ligne de code, tu te retrouves à copier-coller des fichiers YAML pour mettre en place une pipeline CI/CD « comme les pros ».

Résultat : tu attends 3 minutes que ton runner se lance pour découvrir que tu as oublié un point-virgule.

Il existe une alternative bien plus simple.

Le Makefile : ta CI locale

Le Makefile est un outil vieux comme le monde (1976, pour être précis), mais il reste redoutablement efficace. Pour un développeur solo, c’est essentiellement une CI locale instantanée.

	Makefile	Pipeline CI/CD
Vitesse	Instantané	Lent (conteneur, réseau…)
Coût	Gratuit	Gratuit* (limites de l’offre gratuite)
Complexité	Un seul fichier	YAML, secrets, environnements
Déclenchement	Manuel ou Git Hooks	Automatique au push

Pourquoi ça marche bien en solo

1. Standardisation

Peu importe le langage, tes commandes restent les mêmes :

make build
make test
make deploy

Fini le « c’était quoi déjà la commande pour lancer les tests ? »

2. Rapidité

Retour immédiat. Pas de file d’attente, pas de runner à provisionner.

3. Portabilité (avec nuance)

Le jour où tu passes sur une vraie CI, ton Makefile servira de base. En pratique, tu devras quand même adapter certaines choses (gestion du cache, artefacts, parallélisme), mais la logique de tes commandes sera déjà en place. C’est toujours du temps gagné.

Un exemple concret

.PHONY: install test lint build deploy

install:
 npm install

lint:
 npm run lint

test:
 npm test

build:
 npm run build

deploy: lint test build
 @echo "Déploiement en cours..."
 scp -r ./dist user@server:/var/www/mon-projet

Le détail qui tue : deploy dépend de lint, test et build. Impossible de déployer si les tests échouent. C’est une sécurité intégrée, sans configuration supplémentaire.

Attention aux tabulations : les Makefiles exigent des tabulations (pas des espaces) pour l’indentation des commandes. C’est la source d’erreur n°1 quand on débute avec make. Si tu vois Makefile:XX: *** missing separator. Stop., c’est probablement ça.

« Oui mais moi je veux l’automatisation »

Tu veux que ça se lance automatiquement au push ? Utilise les Git Hooks.

Crée un fichier .git/hooks/pre-push :

#!/bin/sh
echo "Vérification avant push..."
make lint && make test

Puis rends-le exécutable :

chmod +x .git/hooks/pre-push

Si les tests ou le lint échouent, le push est annulé.

Ton flux de travail devient :

Tu codes
Tu lances make lint && make test localement
Tu fais un git push
Le hook vérifie une dernière fois
make deploy quand tu es prêt

Limite à connaître : les Git Hooks sont locaux. Ils ne sont pas versionnés par défaut dans le dépôt (le dossier .git/hooks est ignoré par Git). Si tu changes de machine, il faut les reconfigurer. Une astuce : stocke tes hooks dans un dossier scripts/hooks/ versionné et lance git config core.hooksPath scripts/hooks à l’initialisation du projet.

Les limites du Makefile

Le Makefile n’est pas magique. Il faut en connaître les contraintes :

Syntaxe des tabulations : source de frustration classique (voir plus haut)
Windows : make n’est pas installé par défaut. Il faut passer par WSL, Chocolatey ou GnuWin32
Pas de parallélisme multi-environnement : tu ne peux pas tester sur Node 24 et Node 25 en même temps
Pas d’historique : aucune trace visuelle de tes builds passés
Sécurité : si ton déploiement utilise des secrets, ils restent sur ta machine, pas dans un coffre-fort centralisé

Quand passer à une vraie CI/CD ?

Le Makefile montre ses limites quand :

Tu dois tester sur plusieurs OS ou versions simultanément
Tu veux un historique visuel des déploiements
Tu commences à collaborer, le fameux « ça marchait chez moi » devient un vrai problème
Tu as besoin de secrets partagés ou d’environnements de pré-production
Ton processus de déploiement devient trop critique pour dépendre d’un make deploy lancé depuis ton portable

Et bonne nouvelle : ta CI n’aura qu’à appeler les mêmes cibles make que tu utilises déjà.

Le mot de la fin

Commence simple. Un Makefile solide est une base saine qui ne sera jamais perdue.

Ne confonds pas « faire les choses bien » avec « faire les choses de manière compliquée ». Parfois, la solution la plus mature, c’est celle qui te laisse du temps pour coder.