caffeinate sur Mac : éviter la veille pendant un déploiement

Votre terraform apply tourne depuis dix minutes. Vous partez remplir votre tasse. Quand vous revenez, l’écran est noir, le Mac dort, et votre stack CloudFormation est dans un état que personne ne souhaite débugger un vendredi soir.

Ce scénario, nous l’avons vécu chez LCMH lors d’une migration de données S3 pour un client e-commerce alsacien. 47 Go de médias produits, un aws s3 sync lancé à 17h, et un MacBook qui a décidé de faire la sieste au bout de 15 minutes d’inactivité clavier. Résultat : synchronisation partielle, vérification manuelle de chaque fichier le lendemain.

La solution tient en un mot : caffeinate.

Une commande native macOS pour bloquer la mise en veille

caffeinate existe depuis OS X 10.8. Cette commande crée des assertions de gestion d’énergie IOKit qui interdisent au système d’entrer en veille. Pas d’app à télécharger, pas de compte à créer, pas de menu bar à encombrer. Juste le Terminal que vous utilisez déjà pour vos déploiements.

Concrètement, caffeinate intercepte les mêmes signaux que macOS utilise en interne quand une vidéo tourne ou qu’une visioconférence est active. Vous dites au système : “j’ai une tâche en cours, ne dors pas.”

Wrapper vos commandes AWS et Docker avec caffeinate -i

L’usage le plus pertinent pour un contexte DevOps : préfixer votre commande longue avec caffeinate -i. Le Mac reste éveillé exactement le temps de l’exécution, puis reprend son comportement normal.

caffeinate -i terraform apply -auto-approve

caffeinate -i aws s3 sync ./build s3://mon-bucket-production --delete

caffeinate -i docker build --no-cache -t mon-app:latest .

Le flag -i signifie “prevent idle sleep” — il bloque la veille déclenchée par l’inactivité utilisateur. Quand votre commande se termine (succès ou erreur), caffeinate se ferme. Aucun nettoyage nécessaire.

Notre équipe utilise systématiquement ce pattern pour les opérations serverless qui enchaînent packaging, upload S3 et déploiement Lambda. Un sam deploy qui prend 8 minutes ne doit pas être interrompu par une politique d’économie d’énergie.

Garder le Mac éveillé pendant une durée définie

Parfois vous ne wrappez pas une commande unique mais surveillez un processus en arrière-plan. Le flag -t accepte une durée en secondes :

caffeinate -t 3600

Une heure. Le Mac reste éveillé, puis reprend ses réglages normaux. Quelques repères utiles : 30 minutes = 1800, 2 heures = 7200, 4 heures = 14400.

Nous utilisons cette variante quand nous monitorons CloudWatch pendant un déploiement progressif : le terminal affiche les métriques, caffeinate -t garantit que l’écran ne s’éteint pas pendant la fenêtre d’observation.

Empêcher aussi la veille de l’écran avec le flag -d

Par défaut, caffeinate -i empêche la veille système mais laisse l’écran s’éteindre. Si vous surveillez visuellement des logs en temps réel, ajoutez -d :

caffeinate -d -i kubectl logs -f deployment/api-production

Combinez les deux flags quand vous avez besoin de garder un œil sur la sortie sans toucher au clavier.

Créer un alias pour vos déploiements quotidiens

Si vous déployez plusieurs fois par jour, un alias dans ~/.zshrc évite la répétition :

alias awake='caffeinate -i'

Après un source ~/.zshrc, vous écrivez simplement :

awake ./scripts/deploy-staging.sh

Onze caractères de moins à taper. Sur une semaine de sprints, ça s’additionne.

Le flag -s pour les déploiements sur batterie

Situation classique : vous êtes dans le TGV Mulhouse–Paris, vous profitez du trajet pour lancer un hugo deploy vers S3. Sur batterie, macOS est plus agressif sur la mise en veille. Le flag -s force le système à rester éveillé même sans alimentation :

caffeinate -s -i hugo deploy --target production

Attention : cela vide la batterie plus vite. Réservez ce flag aux opérations courtes (moins de 30 minutes) quand vous n’êtes pas branché.

Quand caffeinate ne suffit pas : automatiser côté serveur

caffeinate résout un problème ponctuel. Pour les déploiements critiques et récurrents, nous pensons que la bonne réponse est un pipeline CI/CD qui ne dépend pas de votre machine locale.

Un workflow GitHub Actions ou AWS CodePipeline exécute vos builds sur un serveur distant. Votre Mac peut dormir, se mettre à jour, ou tomber en panne — le déploiement continue. C’est l’approche que nous recommandons systématiquement pour la production.

caffeinate reste l’outil idéal pour les opérations ad hoc : un transfert de fichiers vers un NAS, un export de base de données avant une migration, un build local que vous testez avant de pousser en CI. Pour tout ce qui touche à la production de manière récurrente, l’infrastructure doit être résiliente indépendamment de votre poste de travail.

La prochaine fois que vous lancez une opération longue depuis votre terminal, ces onze caractères — caffeinate -i — sépareront un déploiement réussi d’un vendredi soir gâché.