Lancer un script au démarrage du Mac : guide complet pour automatiser vos tâches

Pour lancer un script au démarrage du Mac, créez un fichier LaunchAgent dans votre dossier utilisateur, référencez le script avec des chemins absolus, puis chargez le service avec launchctl. Cette méthode démarre le script à l’ouverture de votre session, sans modifier les fichiers sensibles de macOS.

Le choix dépend du moment recherché : ouverture de session, démarrage complet du système ou exécution régulière. Ce guide explique comment préparer un script shell ou Python, créer sa configuration launchd, vérifier son fonctionnement, corriger les erreurs et arrêter proprement l’automatisation.

Comment fonctionne le lancement automatique d’un script sur macOS ?

macOS utilise launchd pour charger des tâches en arrière-plan selon leur configuration. Un LaunchAgent concerne la session d’un utilisateur, tandis qu’un LaunchDaemon fonctionne au niveau du système. Pour une automatisation personnelle, le LaunchAgent placé dans ~/Library/LaunchAgents constitue généralement le point de départ le plus prudent.

Un LaunchAgent peut démarrer une tâche après la connexion de l’utilisateur, même si aucune fenêtre n’est visible. Un LaunchDaemon convient plutôt à un service qui doit fonctionner avant la connexion ou indépendamment d’un compte utilisateur, avec des contraintes plus fortes sur les droits et les accès aux fichiers.

Un LaunchAgent convient à une tâche liée à une session utilisateur ; un LaunchDaemon ne doit pas servir de raccourci pour contourner les protections de macOS.

Démarrage du système ou ouverture de session

La formule « démarrer le Mac » recouvre deux situations différentes. Le démarrage du système commence avant l’ouverture de session, alors que l’ouverture de session intervient lorsque macOS a identifié l’utilisateur et préparé son environnement.

Besoin	Configuration adaptée	Dossier habituel	Limite principale
Script personnel après connexion	LaunchAgent	~/Library/LaunchAgents	La session utilisateur doit être ouverte
Service indépendant d’une session	LaunchDaemon	/Library/LaunchDaemons	Configuration et droits plus sensibles
Application visible après connexion	Éléments d’ouverture	Réglages Système	Ne gère pas naturellement un service persistant
Exécution planifiée	launchd avec intervalle ou calendrier	Fichier plist	Le déclenchement n’est pas forcément lié au démarrage

Comment préparer un script avant de l’exécuter automatiquement sur Mac ?

Un script automatisé doit d’abord fonctionner manuellement avec le même interpréteur que celui utilisé par launchd. Préparez un emplacement stable, utilisez des chemins absolus, écrivez les sorties dans un journal et testez les droits avant de créer le service. Cette préparation évite de confondre un problème de script avec une erreur de lancement.

Vérifier que le script fonctionne manuellement

Créez un dossier personnel pour les scripts et ouvrez un fichier avec un éditeur simple. L’exemple suivant écrit une ligne dans un journal à chaque exécution ; il sert uniquement de test contrôlé avant de brancher l’automatisation.

mkdir -p "$HOME/Scripts" "$HOME/Library/Logs"
nano "$HOME/Scripts/mon-script.zsh"

Collez ensuite ce contenu dans l’éditeur :

#!/bin/zsh
set -eu

LOG="$HOME/Library/Logs/mon-script.log"
printf '%s\n' "$(/bin/date '+%Y-%m-%d %H:%M:%S') : script exécuté" >> "$LOG"

Enregistrez le fichier, quittez l’éditeur avec Ctrl + O, validez avec Entrée, puis utilisez Ctrl + X. Rendez le script exécutable et lancez-le manuellement :

chmod u+x "$HOME/Scripts/mon-script.zsh"
"$HOME/Scripts/mon-script.zsh"
cat "$HOME/Library/Logs/mon-script.log"

Le fichier de journal doit contenir une ligne datée. Si cette étape échoue, ne créez pas encore le LaunchAgent : corrigez d’abord le script, son interpréteur ou ses permissions.

Utiliser des chemins absolus et les bons droits

launchd ne fournit pas toujours le même environnement que Terminal. Le chemin de recherche des commandes peut être réduit, le dossier courant peut être différent et les variables personnalisées peuvent manquer.

• Indiquez l’interpréteur dans la première ligne, par exemple #!/bin/zsh ou #!/usr/bin/python3 si ce chemin correspond réellement à votre installation.
• Utilisez des chemins complets pour les fichiers, les dossiers et les commandes importantes.
• Limitez les permissions du script à votre compte avec chmod u+x.
• Écrivez les erreurs dans un fichier séparé plutôt que de compter sur une fenêtre Terminal.

Le chemin d’un script lancé automatiquement doit rester stable entre deux sessions. Évitez les fichiers placés dans le dossier Téléchargements, les volumes externes susceptibles d’être absents et les chemins relatifs comme ./mon-fichier.txt.

Prévoir les sorties et les erreurs

Un script lancé en arrière-plan ne peut pas afficher une question à l’écran de manière fiable. Remplacez les demandes interactives par une configuration explicite ou arrêtez le script avec une erreur lisible.

Si votre automatisation manipule des archives, vérifiez d’abord les commandes utilisées dans Terminal. La méthode pour décompresser un ZIP au Terminal peut servir de base lorsque le script doit traiter des fichiers compressés.

Comment créer un LaunchAgent pour lancer un script à l’ouverture de session ?

Pour lancer un script automatiquement sur Mac à l’ouverture de session, créez un fichier plist dans ~/Library/LaunchAgents, renseignez le chemin complet du script et chargez la configuration dans le domaine graphique de votre utilisateur. La procédure suivante utilise uniquement le Terminal et reste réversible.

1. Étape 1 : créer le dossier du LaunchAgent

   Le dossier personnel peut ne pas exister sur une installation récente. Créez-le avec la commande suivante :

   mkdir -p "$HOME/Library/LaunchAgents" "$HOME/Library/Logs"

   Le dossier appartient à votre compte utilisateur. N’utilisez pas sudo pour cette étape.

2. Étape 2 : générer le fichier de configuration

   La commande suivante crée une configuration liée au script de test. Les variables sont remplacées par le Terminal avant l’écriture du fichier plist, ce qui évite de laisser un chemin fictif dans la configuration.

   PLIST="$HOME/Library/LaunchAgents/com.exemple.script.plist"
   SCRIPT="$HOME/Scripts/mon-script.zsh"
   OUT="$HOME/Library/Logs/mon-script.out.log"
   ERR="$HOME/Library/Logs/mon-script.err.log"
   
   cat > "$PLIST" <<EOF
   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
   <plist version="1.0">
   <dict>
       <key>Label</key>
       <string>com.exemple.script</string>
   
       <key>ProgramArguments</key>
       <array>
           <string>/bin/zsh</string>
           <string>$SCRIPT</string>
       </array>
   
       <key>RunAtLoad</key>
       <true/>
   
       <key>StandardOutPath</key>
       <string>$OUT</string>
   
       <key>StandardErrorPath</key>
       <string>$ERR</string>
   </dict>
   </plist>
   EOF

   RunAtLoad demande le lancement lorsque le service est chargé. Les chemins de sortie séparent le résultat normal des messages d’erreur, ce qui simplifie le dépannage.

3. Étape 3 : vérifier la syntaxe du plist

   Une erreur XML suffit à empêcher le chargement. Contrôlez le fichier avant de le remettre à launchd :

   plutil -lint "$HOME/Library/LaunchAgents/com.exemple.script.plist"

   Le Terminal doit indiquer que le fichier est valide. Un message d’erreur doit être corrigé avant l’étape suivante, notamment si une balise est mal fermée.

4. Étape 4 : charger le service dans votre session

   Le domaine gui/$(id -u) cible la session graphique de l’utilisateur connecté. Utilisez d’abord une sortie de service éventuelle, puis chargez le fichier :

   PLIST="$HOME/Library/LaunchAgents/com.exemple.script.plist"
   
   launchctl bootout "gui/$(id -u)" "$PLIST" 2>/dev/null || true
   launchctl bootstrap "gui/$(id -u)" "$PLIST"
   launchctl print "gui/$(id -u)/com.exemple.script"

   La commande bootout ne signale pas d’erreur si le service n’était pas encore chargé. La commande bootstrap l’enregistre pour la session courante ; la prochaine ouverture de session relancera le LaunchAgent si le fichier reste en place.

Cette configuration lance un script à l’ouverture de session, pas nécessairement au tout premier instant où le Mac reçoit de l’énergie. Le comportement dépend aussi de la durée du script, des volumes disponibles et des autorisations accordées à l’application ou au Terminal.

Comment vérifier qu’un service launchd et son script fonctionnent ?

Vérifiez séparément la présence du service, son état et son résultat. La commande launchctl print confirme que launchd connaît le LaunchAgent, tandis que les journaux montrent si le script a réellement démarré ou s’est arrêté sur une erreur.

Observer le résultat attendu

Après le chargement du service, consultez le journal créé par le script. Le fichier doit afficher une nouvelle ligne à chaque exécution :

tail -n 20 "$HOME/Library/Logs/mon-script.log"

Les fichiers standards du LaunchAgent donnent des informations complémentaires. Le fichier de sortie contient les messages normaux, tandis que le fichier d’erreur révèle les commandes introuvables, les permissions refusées et les chemins invalides :

tail -f "$HOME/Library/Logs/mon-script.out.log"
tail -f "$HOME/Library/Logs/mon-script.err.log"

Consulter l’état du service

Utilisez le label exact déclaré dans le plist. La commande suivante affiche l’état du LaunchAgent dans la session actuelle :

launchctl print "gui/$(id -u)/com.exemple.script"

Un service connu de launchd n’est pas forcément un script réussi. Un processus peut s’être lancé puis arrêté immédiatement ; le journal d’erreur reste donc indispensable pour confirmer le résultat.

Lire les journaux d’exécution

Un fichier de sortie absent peut indiquer que le service n’a jamais été chargé, que le dossier parent n’existe pas ou que le chemin déclaré dans StandardOutPath est incorrect. Un fichier d’erreur rempli indique plutôt que launchd a démarré le programme mais que le programme a rencontré un problème.

Un état actif et un résultat attendu sont deux vérifications différentes. Contrôlez toujours les deux avant de considérer l’automatisation comme terminée.

Comment lancer un script au démarrage complet du système avec un LaunchDaemon ?

Un LaunchDaemon se place dans /Library/LaunchDaemons et fonctionne dans le domaine système, avant ou indépendamment d’une ouverture de session. Cette méthode convient à un service technique réellement global, mais elle impose des droits et un environnement différents d’un LaunchAgent personnel.

Dans quels cas cette méthode est-elle nécessaire ?

Choisissez un LaunchDaemon uniquement si le script doit fonctionner sans utilisateur connecté, desservir plusieurs comptes ou démarrer avant l’ouverture de session. Un script qui sauvegarde les fichiers personnels d’un seul utilisateur reste généralement mieux placé dans son LaunchAgent.

Un LaunchDaemon ne doit pas dépendre d’une fenêtre graphique, du Bureau, d’un trousseau personnel ou d’un dossier situé dans ~/Library. Les chemins accessibles par le compte système et les permissions disponibles ne sont pas les mêmes.

Précautions liées aux droits administrateur

La création et le chargement d’un LaunchDaemon peuvent nécessiter sudo. Le besoin de droits pour installer la configuration ne signifie pas que le script doit être exécuté avec des privilèges administrateur.

• Conservez la configuration dans /Library/LaunchDaemons, pas dans un emplacement personnel.
• Utilisez des chemins absolus qui restent accessibles sans session graphique.
• Évitez d’ajouter des commandes sudo à l’intérieur du script.
• Testez la tâche avec le niveau de droits le plus faible possible.
• Gardez une copie du fichier plist avant toute modification.

Un service système mal configuré peut redémarrer en boucle ou créer des journaux indésirables. Pour cette raison, un LaunchAgent doit rester la première option lorsque l’objectif est simplement d’exécuter un script à la connexion.

Quelles alternatives utiliser pour lancer un script automatiquement sur Mac ?

Les éléments d’ouverture conviennent à une application visible, tandis que Raccourcis ou Automator peuvent emballer une action simple. La planification par cron existe encore dans certains environnements, mais launchd reste plus adapté aux services macOS. La bonne méthode dépend donc du déclencheur, de la persistance et de l’accès requis par le script.

Méthode	Usage recommandé	Avantage	Limite
LaunchAgent	Script personnel à la connexion	Contrôle précis et exécution en arrière-plan	Ne fonctionne pas avant la session
Éléments d’ouverture	Application ou document à ouvrir après connexion	Configuration graphique simple	Peu adapté à un service sans interface
Raccourcis ou Automator	Action composée avec une application compatible	Moins de Terminal pour les opérations simples	Les scripts complexes demandent souvent une configuration complémentaire
LaunchDaemon	Service système sans utilisateur connecté	Fonctionnement indépendant de la session	Droits et dépannage plus sensibles

Utiliser les éléments d’ouverture

Sur les versions récentes de macOS, ouvrez Réglages Système > Général > Ouverture et extensions. Sur des versions plus anciennes, le chemin passe par Préférences Système > Utilisateurs et groupes > Ouverture.

Le bouton d’ajout permet de sélectionner une application, et le bouton de retrait supprime l’élément de la liste. Cette méthode peut démarrer une application qui sert ensuite à exécuter une action, mais elle ne remplace pas un LaunchAgent pour un script sans interface ou un processus qui doit être surveillé.

Passer par Automator ou Raccourcis

Automator et Raccourcis peuvent convenir lorsque la tâche repose sur des actions proposées par macOS. Une automatisation qui nécessite un interpréteur précis, des variables, des journaux et un redémarrage contrôlé reste plus prévisible dans un script lancé par launchd.

Programmer une exécution régulière

Un déclenchement régulier ne correspond pas toujours au démarrage. Pour une fréquence ou un calendrier, configurez la planification dans un fichier launchd avec un intervalle ou un calendrier adapté. La crontab peut exécuter des commandes planifiées dans certains environnements, mais elle n’offre pas le même cadre de gestion que launchd sur macOS.

Le fichier /etc/rc.local appartient à des pratiques courantes sur certains systèmes Linux. Ce fichier ne constitue pas une méthode native générale pour macOS et ne doit pas être copié depuis un tutoriel destiné à un autre système.

Quelles erreurs empêchent un script de se lancer automatiquement ?

Les échecs les plus fréquents viennent d’un environnement différent de Terminal, d’un plist invalide ou d’un service chargé plusieurs fois. La résolution consiste à vérifier dans l’ordre le chemin du script, ses droits, la syntaxe du plist, l’état launchd et les journaux d’erreur.

Le script fonctionne dans Terminal mais pas avec launchd

Terminal fournit souvent un environnement plus riche que launchd. Une commande disponible grâce au PATH du shell peut être introuvable dans le service, et un chemin relatif peut pointer vers un autre dossier.

Remplacez les commandes courtes par des chemins complets, par exemple /bin/date au lieu de date lorsque le contexte l’exige. Ajoutez une trace temporaire au script pour enregistrer la valeur de PATH, du dossier courant et des variables utiles.

Le service est chargé plusieurs fois

Un doublon peut apparaître après plusieurs créations de plist ou après un chargement répété. Le même label ne doit pas être déclaré dans plusieurs fichiers actifs, car le diagnostic devient ambigu.

Conservez un label unique, recherchez les fichiers qui portent le même nom dans ~/Library/LaunchAgents et utilisez launchctl bootout avant de recharger une configuration modifiée.

macOS bloque l’accès à un fichier ou à un dossier

Les protections de confidentialité de macOS peuvent limiter l’accès à certains dossiers, notamment les données personnelles, les fichiers d’une autre application ou des emplacements protégés. Un script lancé automatiquement ne doit pas recevoir plus d’autorisations que nécessaire.

Identifiez précisément le fichier refusé, vérifiez les permissions et accordez l’autorisation correspondante dans les réglages de confidentialité seulement si l’usage est légitime. Ne désactivez pas globalement les protections de macOS pour contourner une erreur.

Le script ne se lance plus après une modification

Une modification du chemin, du label ou des balises XML peut rendre le service invalide. Relancez plutil -lint, consultez le journal d’erreur et rechargez le service après avoir quitté l’ancienne instance.

Une modification du plist n’est pas toujours prise en compte par un service déjà chargé. Un cycle propre de sortie puis de chargement permet de tester la version réellement utilisée par launchd.

Comment arrêter un script automatique sur Mac ?

Pour arrêter temporairement un LaunchAgent, retirez-le du domaine de session avec launchctl bootout sans supprimer le fichier plist. Pour désactiver définitivement l’automatisation, arrêtez le service, déplacez ou supprimez sa configuration, puis vérifiez qu’aucun processus ne reste actif.

Désactiver temporairement le service

Utilisez le chemin complet du fichier plist :

PLIST="$HOME/Library/LaunchAgents/com.exemple.script.plist"
launchctl bootout "gui/$(id -u)" "$PLIST"

Le script ne sera plus lancé par l’instance actuelle de launchd. Le fichier reste disponible pour une réactivation ultérieure avec launchctl bootstrap.

Réactiver l’automatisation

Rechargez le même fichier après avoir vérifié sa syntaxe :

PLIST="$HOME/Library/LaunchAgents/com.exemple.script.plist"
plutil -lint "$PLIST"
launchctl bootstrap "gui/$(id -u)" "$PLIST"

Supprimer définitivement la configuration

Arrêtez d’abord le service, puis retirez le fichier de configuration. La commande suivante conserve une copie renommée dans le même dossier avant suppression complète :

PLIST="$HOME/Library/LaunchAgents/com.exemple.script.plist"
launchctl bootout "gui/$(id -u)" "$PLIST" 2>/dev/null || true
mv "$PLIST" "$PLIST.disabled"

Contrôlez ensuite l’absence du processus avec launchctl print ou l’outil d’activité correspondant au script. Un programme lancé en arrière-plan peut continuer quelques instants après le retrait du LaunchAgent s’il n’a pas encore terminé.

Sources utiles à consulter

La documentation Apple sur la création des tâches de démarrage décrit le rôle de launchd, des agents et des démons : documentation Apple sur les tâches launchd. Cette page explique la logique générale des fichiers plist et des emplacements de configuration.

Le guide Apple consacré aux éléments ouverts à la connexion présente la gestion des applications lancées automatiquement : guide Apple sur les éléments d’ouverture. Cette source est préférable pour vérifier le nom exact des menus selon la version de macOS utilisée.

Le manuel local de macOS reste utile pour les détails de commande. Dans Terminal, utilisez man launchctl et man launchd.plist afin de consulter les options disponibles sur votre version installée.

Pour une tâche personnelle, commencez par un LaunchAgent minimal, testez le script dans Terminal et ajoutez les dépendances une par une. Cette progression limite les droits nécessaires et permet de retirer l’automatisation sans toucher aux fichiers sensibles de macOS.

Questions fréquentes

Peut-on lancer un script uniquement lorsque l’utilisateur se connecte ?

Oui. Un LaunchAgent placé dans ~/Library/LaunchAgents et associé à RunAtLoad démarre lorsque le service est chargé dans la session graphique de l’utilisateur. Cette configuration ne demande pas de LaunchDaemon.

Peut-on lancer un script avec des droits administrateur ?

C’est possible dans certains cas, mais l’installation d’un service avec sudo ne justifie pas l’exécution permanente du script en administrateur. Préférez un LaunchAgent et des permissions limitées lorsque la tâche concerne vos propres fichiers.

Comment savoir si le script est actif ?

La commande launchctl print "gui/$(id -u)/com.exemple.script" indique si launchd connaît le service. Les fichiers définis par StandardOutPath et StandardErrorPath permettent ensuite de vérifier ce que le script a réellement fait.

Quelle méthode choisir pour un script Python ou shell ?

Les deux langages peuvent être lancés par un LaunchAgent si l’interpréteur et le chemin du script sont corrects. Vérifiez le chemin réel de Python, les modules utilisés et les variables d’environnement, car l’exécution automatique ne reproduit pas toujours votre session Terminal.

Comment arrêter un script automatique sur Mac ?

Utilisez launchctl bootout avec le domaine et le fichier plist concernés. Pour empêcher une réactivation future, renommez ou supprimez ensuite le fichier de configuration après avoir conservé une copie si nécessaire.