Transformer un raspberry pi en écran d’affichage ou borne en lançant automatiquement une page web au démarrage, en plein écran, demande plus qu’une simple commande: il faut choisir une méthode adaptée (kiosque, bureau, headless), attendre le réseau au bon moment et éviter les pièges classiques d’affichage (HDMI, veille, session graphique). Les recettes ci-dessous s’appuient sur Raspberry Pi OS, Chromium et des mécanismes éprouvés (autostart LXDE, systemd, cron), avec des commandes prêtes à copier et une checklist de dépannage souvent oubliée, pourtant décisive en usage 24/24.
- Pour un kiosque fiable: privilégier systemd avec attente réseau (network-online.target) et redémarrage automatique.
- Pour un poste avec session graphique: autostart LXDE reste le plus simple à maintenir.
- Pour du headless: éviter Chromium sans affichage, préférer un service web local et des vérifications réseau via systemd/cron.
- Stabiliser l’affichage: désactiver DPMS, masquer le curseur (unclutter) et sécuriser la sortie HDMI.
- Dépanner vite: journaux systemd via journalctl, test URL, état réseau, et cohérence X11/Wayland/lightdm.
Choisir la bonne méthode selon votre usage (kiosque, bureau, headless)
L’objectif est simple: ouvrir automatiquement une page web au démarrage, en plein écran, en lançant un navigateur pointant sur une URL définie. Mais la méthode change radicalement selon le scénario, et c’est là que beaucoup de projets kiosque se fragilisent: un script qui marche « à la main » ne survit pas toujours au reboot, aux coupures wifi ou à une mise à jour de l’environnement graphique.
Trois scénarios couvrent l’essentiel des usages sur Raspberry Pi OS:
- Kiosque plein écran: un écran (souvent HDMI) affiche une page unique en continu, sans bureau visible. C’est l’usage borne, affichage dynamique, supervision (on voit des installations avec plusieurs raspberry pi, par exemple 4 unités pour du monitoring) et fonctionnement visé 24/24.
- Interface locale (bureau): un utilisateur ouvre une session graphique et vous voulez lancer automatiquement Chromium à l’ouverture de session, tout en gardant l’environnement (LXDE + OpenBox par exemple).
- Usage headless: pas d’écran, accès SSH. L’objectif n’est pas « afficher », mais servir une page locale (http://localhost) ou vérifier qu’une URL est joignable. Vouloir lancer Chromium en headless peut se faire, mais ce n’est pas le plus maintenable si vous n’avez aucun affichage.
Pour comparer systemd, autostart et cron, le critère n°1 est la fiabilité au boot: qui attend le réseau, qui sait redémarrer en cas de crash, et qui fournit des logs exploitables. Le critère n°2 est la maintenance: un fichier simple à relire, un comportement stable après mise à jour, et une séparation propre des droits (ne pas tout exécuter en root).
| Méthode | Idéale pour | Forces | Limites |
|---|---|---|---|
| autostart (LXDE) | bureau / session utilisateur | simple, lisible, proche du poste | dépend de la session graphique et du timing réseau |
| systemd | kiosque robuste, services | attentes (réseau, graphique), restart, journalctl | un peu plus long à écrire au départ |
| cron @reboot | tâches simples, headless | rapide, connu | peu de contrôle fin, logs à organiser |
Avec ce cadre, on peut répondre concrètement à: comment lancer un site web au démarrage automatique ? En choisissant d’abord où l’exécution doit se déclencher (session LXDE, cible graphique systemd, ou simple reboot), puis en sécurisant ce qui manque le plus souvent: réseau prêt, session graphique, gestion de l’alimentation écran.
Pré-requis au démarrage: réseau prêt, session graphique, gestion de l’alimentation écran.
Pré-requis au démarrage: réseau prêt, session graphique, gestion de l’alimentation écran
Si la page ne s’ouvre pas « une fois sur trois », ce n’est généralement pas Chromium: c’est l’ordre de démarrage. Au boot, le wifi peut être connecté après le lancement, le DNS peut répondre lentement, et la session X11 peut ne pas être prête. Sur Raspberry Pi OS, selon la configuration, vous pouvez être en X11 ou Wayland, avec un gestionnaire de connexion comme lightdm côté X11. Un script qui tente de lancer un navigateur avant l’apparition du serveur d’affichage échouera silencieusement.
Checklist pragmatique avant toute automatisation:
- Réseau: vérifier que l’interface est up et qu’une route par défaut existe. En kiosque, l’attente via network-online.target est souvent la différence entre « fiable » et « aléatoire ».
- DNS: si l’URL est un nom de domaine, tester la résolution. En cas de fragilité, une URL locale (http://localhost) ou une IP peut servir de page de secours.
- Session graphique: confirmer si vous lancez sous X11 (avec DISPLAY) ou Wayland. Pour un kiosque classique, X11 reste courant car de nombreux outils (xset, unclutter) s’y intègrent facilement.
- Veille écran: désactiver DPMS et l’économiseur, sinon vous aurez un écran noir malgré un Chromium actif.
- Curseur: masquer le pointeur pour un rendu borne avec unclutter.
Commandes utiles côté affichage (X11):
- xset s off (désactive l’économiseur)
- xset -dpms (désactive DPMS)
- xset s noblank (évite le blank)
- unclutter -idle 0.5 -root (masque le curseur)
Pour répondre à: comment lancer automatiquement un programme au démarrage de Linux ? La règle est de lier le démarrage aux dépendances: réseau prêt, cible graphique atteinte, et droits corrects. systemd sait le faire proprement; autostart le fait au niveau session; cron le fait sans contexte graphique.
Démarrer Chromium en plein écran: mode kiosque et options essentielles.
Démarrer Chromium en plein écran: mode kiosque et options essentielles
La recette kiosque consiste à lancer Chromium avec des options adaptées à l’affichage continu. L’URL peut être distante (site public, intranet) ou locale (http://localhost:8080) si vous servez une page depuis le raspberry pi. Cette seconde approche est souvent plus robuste: même si internet tombe, l’interface reste accessible.
Commande type (à adapter):
chromium-browser –kiosk –incognito –disable-infobars –noerrdialogs –disable-translate –check-for-update-interval=31536000 « https://exemple.tld/chemin »
Options à connaître:
- –kiosk: plein écran sans chrome d’interface, c’est le cœur du mode kiosque.
- –incognito: limite la persistance de session, utile en borne.
- –noerrdialogs: évite certaines boîtes de dialogue bloquantes.
- –disable-translate: supprime des pop-ups de traduction.
- Rafraîchissement: plutôt que des hacks, privilégier un auto-refresh dans la page (côté application). Dans des cas de supervision, on vise une génération rapide des pages; un exemple mentionne 0.038 secondes, ce qui rend le rafraîchissement fréquent réaliste sans charger le pi.
Si vous comparez avec d’autres navigateurs: des retours indiquent epiphany comme pouvant planter assez souvent sur des exécutions longues, tandis que Midori est décrit comme plus stable, plus rapide et plus léger. Chromium reste toutefois un choix courant sur Raspberry Pi OS pour sa compatibilité web, mais gardez cette alternative en tête si vous cherchez la légèreté.
Pour une page locale:
chromium-browser –kiosk « http://localhost »
Pour répondre à: comment démarrer un Raspberry Pi sur une page Web en plein écran ? La réponse opérationnelle est: une commande Chromium avec –kiosk, lancée au bon moment (session graphique prête) et après réseau prêt si l’URL est distante.
Lancement automatique en environnement graphique: autostart (LXDE) et variantes.
Lancement automatique en environnement graphique: autostart (LXDE) et variantes
Quand vous utilisez LXDE (souvent avec OpenBox), la méthode la plus directe est le fichier autostart, exécuté à l’ouverture de session. C’est précisément ce qui est recommandé dans des guides réalisés sous raspbian (nom de code « jessie ») et annoncés comme applicables sous raspbian stretch: la logique reste valable sur Raspberry Pi OS dès lors que vous êtes en session LXDE.
Chemin par utilisateur (à créer si absent): ~/.config/lxsession/LXDE/autostart. Point important: l’édition se fait avec l’utilisateur de la session graphique, pas en sudo, pour éviter des droits incohérents.
Exemple d’autostart minimal:
@xset s off @xset -dpms @xset s noblank @unclutter -idle 0.5 -root @bash -lc ‘sleep 5; chromium-browser –kiosk –incognito « https://exemple.tld »‘
Le sleep est un amortisseur simple si le réseau ou lightdm met quelques secondes à stabiliser la session. Pour éditer via nano, la séquence de sortie typique est: ctrl + x, puis Y, puis entrée.
Variante utile si votre Raspberry Pi OS n’est pas en LXDE: cherchez l’équivalent dans l’environnement (fichiers de démarrage de session). Mais si votre objectif est un kiosque « borne » sans bureau, autostart devient moins adapté: il dépend d’une session utilisateur, donc d’une connexion automatique configurée.
Pour répondre à: comment lancer automatiquement un programme au démarrage d’un Raspberry Pi ? autostart est souvent la réponse la plus courte quand une session graphique démarre déjà. Pour une fiabilité kiosque, la suite logique est de passer à systemd.
Solution robuste avec systemd: service kiosque, redémarrage et logs.
Solution robuste avec systemd: service kiosque, redémarrage et logs
systemd est la voie la plus maintenable pour un kiosque: dépendances explicites, redémarrage automatique, et journaux consultables via journalctl. L’idée: créer un service qui démarre Chromium après la cible graphique et après que le réseau soit réellement en ligne (pas seulement « l’interface existe »). C’est ici que network-online.target devient central.
Exemple de service (mode user, recommandé si vous avez une session graphique et un utilisateur kiosque dédié). Créez ~/.config/systemd/user/kiosk.service:
[Unit] Description=Chromium kiosk Wants=network-online.target After=network-online.target graphical-session.target [Service] Type=simple Restart=always RestartSec=2 Environment=DISPLAY=:0 ExecStart=/usr/bin/chromium-browser –kiosk –incognito –noerrdialogs « https://exemple.tld » [Install] WantedBy=default.target
Puis:
systemctl –user daemon-reload systemctl –user enable –now kiosk.service
Si vous êtes en X11 avec lightdm, assurez-vous que DISPLAY et la session sont cohérents. Sur Wayland, les variables et le contexte diffèrent; dans ce cas, privilégiez un service user démarré par la session plutôt qu’un service system global qui « devine » l’affichage.
Côté logs, la différence est immédiate:
journalctl –user -u kiosk.service -e
En service system (plus proche d’un démarrage « avant login », comme l’approche historique via rc.local), vous gagnerez en contrôle global, mais vous devrez gérer proprement l’accès à l’affichage et éviter d’exécuter Chromium en root. Créer un utilisateur dédié kiosque, limiter les droits, et isoler l’URL et les paramètres dans un script lisible rendent l’ensemble durable.
Pour répondre à: comment lancer automatiquement un programme au démarrage de Linux ? systemd est le standard moderne: il remplace avantageusement rc.local et dépasse cron @reboot dès que vous avez des dépendances réseau, des redémarrages et des logs.
Dépannage et bonnes pratiques: écran noir, url qui ne charge pas, redémarrages en boucle.
Dépannage et bonnes pratiques: écran noir, url qui ne charge pas, redémarrages en boucle
Un kiosque se juge sur sa capacité à se rétablir seul. Quand ça casse, il faut diagnostiquer vite, sans suppositions. Grille de contrôle, du plus fréquent au plus discriminant:
- Le mécanisme de démarrage s’exécute-t-il: autostart lu, service systemd actif, cron déclenché.
- L’URL charge-t-elle: test local, puis DNS, puis route.
- L’affichage est-il prêt: X11/Wayland, DISPLAY, lightdm.
- L’écran est-il en veille: DPMS, économiseur, câble HDMI.
- Chromium est-il bloqué: profil corrompu, cache, pop-up, crash en boucle.
Commandes de base:
- État service: systemctl –user status kiosk.service ou systemctl status kiosk.service
- Logs: journalctl –user -u kiosk.service -e ou journalctl -u kiosk.service -e
- Réseau: ip a, ip r, ping -c 1 1.1.1.1, ping -c 1 exemple.tld
- URL: curl -I http://localhost ou curl -I « https://exemple.tld »
Écran noir alors que le service tourne: suspectez DPMS ou un souci HDMI (résolution négociée). Un test simple consiste à lancer un terminal sur la session et exécuter xset q pour vérifier l’état DPMS. Si le curseur gêne l’esthétique, vérifiez qu’unclutter tourne bien.
URL qui ne charge pas au boot mais marche après: c’est typiquement un manque d’attente réseau. Corrigez en ajoutant Wants=network-online.target et After=network-online.target côté systemd, ou en ajoutant un délai raisonnable côté autostart. Pour les environnements instables, prévoyez une page locale de secours (http://localhost) qui affiche un message « réseau indisponible » et bascule vers l’URL distante dès qu’elle redevient joignable.
Redémarrages en boucle: si Chromium crash et que systemd relance immédiatement, vous perdez la main. Augmentez RestartSec, et testez la commande ExecStart à la main dans la session. Un profil corrompu peut se régler en pointant vers un répertoire dédié: –user-data-dir=/home/kiosk/chromium-profile. En dernier recours, testez un navigateur alternatif plus léger, comme Midori, si votre page est simple.
Conflit Wayland/X11: si vos commandes xset ou unclutter ne font rien, vous n’êtes probablement pas dans une session X11. Vérifiez la configuration de Raspberry Pi OS, et alignez votre méthode (service user lié à la session, ou retour à X11 si votre stack kiosque en dépend).
Pour répondre à: comment lancer un site web au démarrage automatique ? La réponse complète inclut la méthode de lancement et ce plan de dépannage: sans réseau prêt, sans session graphique cohérente et sans gestion de l’alimentation écran, le démarrage automatique restera aléatoire.
FAQ
Comment lancer un site web au démarrage automatique ?
Choisissez autostart (LXDE) si une session graphique utilisateur démarre, ou systemd si vous voulez une exécution robuste avec attente réseau (network-online.target) et redémarrage automatique, puis lancez Chromium avec l’URL en mode kiosque.
Comment démarrer un Raspberry Pi sur une page Web en plein écran ?
Lancez Chromium avec –kiosk et l’URL, en vous assurant que l’affichage est prêt (X11/Wayland) et que DPMS est désactivé pour éviter l’écran noir.
Comment lancer automatiquement un programme au démarrage d’un Raspberry Pi ?
En environnement LXDE, modifiez ~/.config/lxsession/LXDE/autostart; pour un kiosque plus fiable, créez un service systemd qui démarre après le réseau et la session graphique.
Comment lancer automatiquement un programme au démarrage de Linux ?
systemd est la méthode la plus maintenable: dépendances explicites, restart, et diagnostics via journalctl; cron @reboot convient à des tâches simples, surtout en headless.
Un kiosque stable sur Raspberry Pi OS repose sur une règle: l’automatisation ne vaut que si ses dépendances sont maîtrisées. En combinant une commande Chromium propre, une attente réseau explicite et une gestion stricte de l’affichage, vous obtenez une borne qui redémarre seule et se dépanne en quelques minutes, pas en tâtonnant.
