Rien ne dit « bon matin » comme ouvrir un portable et le voir s’illuminer avec six applications qui démarrent automatiquement sans que vous les ayez demandées. Les ventilateurs s’emballent, le client VPN se dispute avec le Wi‑Fi, et Teams décide que c’est la chose la plus importante de votre vie — encore une fois.
Si vous avez essayé « désactiver dans le Gestionnaire des tâches » et que l’application est revenue quand même, vous n’êtes pas fou. Vous avez juste découvert la réalité : le démarrage de Windows n’est pas une chose unique. C’est un ensemble de mécanismes. Il faut fermer les bonnes portes, dans le bon ordre, et avec des preuves.
Pourquoi ça revient (le démarrage est une hydre)
Quand les gens disent « une application démarre avec Windows », ils imaginent généralement un seul interrupteur. Windows propose une interface conviviale pour une partie de ces mécanismes. Mais le système prend aussi en charge :
- Dossiers de démarrage (par utilisateur et pour tous les utilisateurs)
- Clés de registre « Run » (par utilisateur et machine)
- Services (certaines apps déguisées en service)
- Tâches planifiées (déclencheurs au logon, au démarrage, « en veille », ou « toutes les 5 minutes indéfiniment »)
- Stratégie de groupe (application qui rétablit discrètement votre « correctif »)
- Réparation/auto‑réinstallation de l’installateur (réinstalle une entrée d’autostart lors d’une « mise à jour »)
- Paramètres gérés par l’application (l’application réécrit les clés au lancement)
La raison pour laquelle votre changement « ne tient pas » est généralement l’une de celles-ci :
- Vous avez désactivé l’entrée à un endroit, mais elle existe à deux autres.
- Une tâche planifiée réajoute la clé de registre au prochain login.
- L’entrée est dans HKLM, mais vous l’avez désactivée dans HKCU (ou inversement).
- La GPO ou l’MDM la réapplique, parce que la vie en entreprise repose sur le contrôle.
- Vous avez désactivé la mauvaise chose et l’application « échoue ouvert » en utilisant un autre chemin de démarrage.
La méthode PowerShell qui tient vraiment n’est pas une seule commande. C’est un flux de travail discipliné :
- Inventorier tous les mécanismes d’autostart.
- Désactiver avec intention (et dans la bonne portée : utilisateur vs machine).
- Vérifier après redémarrage et après un cycle de mise à jour.
- Conserver des données de restauration pour annuler sans drame.
Une citation opérationnelle à garder sur votre bureau : L’espoir n’est pas une stratégie.
— General Gordon R. Sullivan. En exploitation, l’espoir ressemble à « je l’ai désactivé une fois dans le Gestionnaire des tâches et j’en ai fini ». Ne faites pas ça.
Faits intéressants et courte histoire (pourquoi le démarrage est ainsi)
- Les dossiers de démarrage précèdent les modèles de sécurité Windows modernes. C’est une simple fonctionnalité du shell : placez un raccourci ici, il s’exécute au logon.
- Les clés de registre « Run » ont été conçues pour la commodité. Elles sont devenues un mécanisme standard pour les installateurs bien avant que le principe du moindre privilège ne soit en vogue.
- Le Planificateur de tâches est plus ancien que la plupart des « gestionnaires d’autostart ». Il est extrêmement capable, ce qui signifie qu’il est aussi extrêmement abusé.
- Les services Windows ne sont pas que de la tuyauterie OS. Les éditeurs exécutent des agents de mise à jour et des outils de synchronisation en arrière‑plan en tant que services, car ils démarrent tôt et peuvent fonctionner sans session utilisateur.
- Windows 64 bits a deux « vues » de certains chemins de registre. La redirection peut vous faire désactiver une vue tandis que l’autre lance toujours des composants.
- La persistance de type Autoruns est un problème de sécurité, pas seulement une question de commodité. Les malwares et les logiciels « légitimes » utilisent les mêmes surfaces d’autostart.
- L’onglet Démarrage du Gestionnaire des tâches est filtré. Il n’affiche pas tout. Il montre ce que Microsoft a décidé d’exposer à l’utilisateur et de rendre à peu près sûr à basculer.
- Les scripts de démarrage/logon GPO existent toujours. Ils sont ennuyeux, fiables, et fréquemment la main invisible derrière « ça revient toujours ».
Blague n°1 (courte et pertinente) : Windows a tellement de chemins de démarrage que « désactiver le démarrage » ressemble à une chasse au trésor — sauf que le prix, c’est moins de processus en arrière‑plan.
Tactique de diagnostic rapide (vérifiez ces éléments d’abord)
Quand une machine démarre lentement ou lance des applications indésirables, ne commencez pas immédiatement à supprimer des clés de registre comme en 2009. Agissez vite, mais avec une carte.
Première étape : identifier le mécanisme (dossier vs registre vs tâche vs service)
- Les déclencheurs du Planificateur de tâches (logon/démarrage) sont la raison n°1 pour laquelle une application « désactivée » ressuscite.
- Les clés Run sont la raison n°1 pour laquelle une application apparaît instantanément après la connexion.
- Les services sont la raison n°1 pour laquelle vous l’« avez désactivée » mais qu’elle s’exécute toujours en arrière‑plan sans interface utilisateur.
Deuxième étape : identifier la portée (par utilisateur vs machine)
- Si cela se produit pour tous les utilisateurs, suspectez HKLM, le dossier de démarrage Tous les utilisateurs, les services, les tâches planifiées ou la GPO.
- Si cela se produit pour un seul utilisateur, suspectez HKCU, le dossier de démarrage par utilisateur ou les paramètres du profil de l’application.
Troisième étape : prouver la persistance du changement
- Redémarrez une fois pour valider la ligne de base.
- Déclenchez un cycle de mise à jour (ou attendez‑le) et revérifiez.
- Si géré par l’IT, exécutez un rafraîchissement des stratégies et revérifiez.
La carte des autostarts : tous les endroits où les apps se glissent
Voici les surfaces qui comptent dans la réalité. Si vous couvrez celles‑ci, vous attrapez la plupart des comportements d’autostart « collants » sans devenir analyste judiciaire.
1) Dossiers de démarrage
- Par utilisateur :
%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup - Tous les utilisateurs :
%ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup
Ce sont des instruments brutaux. S’il y a un raccourci, il s’exécute. Si vous le supprimez, il ne s’exécute pas. Le souci : les installateurs aiment y déposer des raccourcis ; les utilisateurs aiment aussi y déposer des absurdités.
2) Clés de registre Run
- Par utilisateur :
HKCU\Software\Microsoft\Windows\CurrentVersion\Run - Machine :
HKLM\Software\Microsoft\Windows\CurrentVersion\Run - Vérifiez aussi :
...\RunOncepour des actions de démarrage une fois
Les clés Run sont le mécanisme classique « lancer ceci au logon ». Elles sont faciles à définir, faciles à abuser, et agaçantes lors des mises à niveau.
3) Tâches planifiées
Les tâches peuvent être configurées avec des déclencheurs comme :
- Au logon (n’importe quel utilisateur ou utilisateur spécifique)
- Au démarrage
- En veille
- Au déverrouillage de station
- Sur une entrée du journal d’événements
Si un éditeur veut de la « fiabilité », il utilise le Planificateur de tâches. S’il veut de la « persistance », il l’utilise aussi. Même outil, vibes différentes.
4) Services
Les services démarrent avant que vous ne vous connectiez et peuvent tourner indéfiniment. Si une app a un « service de mise à jour » ou un « helper », il peut lancer le processus visible par l’utilisateur après la connexion. Désactiver l’autostart de l’UI peut ne rien changer parce que le service le redémarre.
5) Stratégie de groupe / MDM
La GPO peut déployer des tâches planifiées, définir des entrées de registre, exécuter des scripts au logon, et plus. Les profils MDM peuvent appliquer des configurations similaires. L’idée opérationnelle clé : si la stratégie en est propriétaire, votre modification locale est une illusion temporaire.
Tâches pratiques avec commandes, sorties et décisions
Ci‑dessous se trouvent des tâches réelles à exécuter depuis PowerShell. J’utilise une invite de style shell dans les blocs de code pour la cohérence ; exécutez les commandes dans un PowerShell élevé si nécessaire. Chaque tâche inclut : la commande, ce que signifie une sortie typique, et la décision suivante.
Tâche 1 : Vue rapide des éléments du dossier de démarrage utilisateur
cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Force \"$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\" | Select-Object Name,FullName"
Name FullName
---- --------
Teams.lnk C:\Users\alice\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\Teams.lnk
OneDrive.lnk C:\Users\alice\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\OneDrive.lnk
Ce que ça signifie : Les raccourcis dans ce dossier s’exécutent au logon pour cet utilisateur.
Décision : Si l’application indésirable est ici, supprimez le raccourci (ou déplacez‑le dans un dossier de quarantaine) plutôt que de « désactiver » dans l’interface.
Tâche 2 : Vérifier le dossier de démarrage pour tous les utilisateurs
cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Force \"$env:ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\" | Select Name,FullName"
Name FullName
---- --------
VendorUpdater.lnk C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\VendorUpdater.lnk
Ce que ça signifie : Tout ce qui est ici touche chaque utilisateur qui se connecte à la machine.
Décision : Si c’est une image d’entreprise, confirmez avec les propriétaires de la politique IT avant de supprimer ; sinon la prochaine application de la baseline la remettra.
Tâche 3 : Énumérer les entrées Run HKCU (par utilisateur)
cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run' | Select-Object * -ExcludeProperty PS*"
OneDrive : "C:\Program Files\Microsoft OneDrive\OneDrive.exe" /background
Teams : "C:\Users\alice\AppData\Local\Microsoft\Teams\current\Teams.exe" --processStart "Teams.exe"
Ce que ça signifie : Ces valeurs s’exécutent au logon pour cet utilisateur.
Décision : Si une app est ici, supprimez seulement cette valeur — ne supprimez pas la clé entière. Sauvegardez d’abord la valeur existante pour restauration.
Tâche 4 : Énumérer les entrées Run HKLM (machine)
cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Run' | Select-Object * -ExcludeProperty PS*"
SecurityHealth : %windir%\system32\SecurityHealthSystray.exe
VendorAgent : "C:\Program Files\Vendor\Agent\agent.exe" --startup
Ce que ça signifie : Celles‑ci s’exécutent pour tous les utilisateurs au logon. Requiert les droits administrateur pour modifier.
Décision : Si c’est un agent fournisseur à but corporatif (sécurité, conformité), ne le désactivez pas à la légère. Si c’est du bloat, désactivez‑le en enregistrant le changement et avec un plan de restauration.
Tâche 5 : Exporter les clés Run avant de les toucher (assurance restauration)
cr0x@server:~$ powershell -NoProfile -Command "reg export 'HKCU\Software\Microsoft\Windows\CurrentVersion\Run' $env:TEMP\hkcu-run-backup.reg /y; reg export 'HKLM\Software\Microsoft\Windows\CurrentVersion\Run' $env:TEMP\hklm-run-backup.reg /y; dir $env:TEMP\*-run-backup.reg"
Directory: C:\Users\alice\AppData\Local\Temp
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 2/5/2026 9:14 AM 1320 hkcu-run-backup.reg
-a---- 2/5/2026 9:14 AM 1987 hklm-run-backup.reg
Ce que ça signifie : Vous avez maintenant un chemin de restauration qui ne dépend pas de votre mémoire.
Décision : Si vous ne pouvez pas ou ne voulez pas faire de sauvegarde, vous n’êtes pas prêt à modifier la machine de quelqu’un d’autre.
Tâche 6 : Supprimer une valeur Run HKCU spécifique (changement ciblé)
cr0x@server:~$ powershell -NoProfile -Command "Remove-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run' -Name 'Teams' -ErrorAction Stop; 'Removed HKCU Run value: Teams'"
Removed HKCU Run value: Teams
Ce que ça signifie : La valeur a disparu. Elle ne se lancera plus via ce mécanisme.
Décision : Revérifiez après redémarrage. Si elle revient, vous avez affaire à une tâche, un service, une stratégie, ou l’application qui réécrit sa propre clé.
Tâche 7 : Lister les tâches planifiées déclenchées au logon ou au démarrage
cr0x@server:~$ powershell -NoProfile -Command "Get-ScheduledTask | Where-Object { ($_.Triggers | Out-String) -match 'Logon|Startup' } | Select-Object TaskName,TaskPath,State | Sort-Object TaskPath,TaskName | Format-Table -AutoSize"
TaskName TaskPath State
-------- -------- -----
Vendor Updater \Vendor\ Ready
Teams Update Task \Microsoft\Teams\ Ready
OneDrive Standalone \Microsoft\OneDrive\ Ready
Ce que ça signifie : Ce sont des candidats pour « ça revient ». Les détails des déclencheurs sont simplifiés ici ; leur présence est votre indice.
Décision : Inspectez l’action et le principal de la tâche spécifique avant de désactiver. Certaines tâches s’exécutent sous SYSTEM ; d’autres uniquement au logon d’un utilisateur.
Tâche 8 : Inspecter une tâche planifiée spécifique (action + déclencheur + exécution)
cr0x@server:~$ powershell -NoProfile -Command "$t=Get-ScheduledTask -TaskName 'Teams Update Task' -TaskPath '\Microsoft\Teams\'; $t | Select-Object TaskName,State; $t.Principal | Select-Object UserId,LogonType,RunLevel; $t.Actions | Select-Object Execute,Arguments; $t.Triggers | Select-Object *"
TaskName State
-------- -----
Teams Update Task Ready
UserId LogonType RunLevel
------ --------- --------
SYSTEM ServiceAccount Highest
Execute Arguments
------- ---------
C:\Users\alice\AppData\Local\Microsoft\Teams\Update.exe --processStart "Teams.exe"
Enabled : True
Delay : PT30S
UserId :
Ce que ça signifie : Cette tâche s’exécute en tant que SYSTEM et lance un outil de mise à jour qui peut relancer l’application. Désactiver HKCU Run ne suffira pas.
Décision : Si vous avez besoin de l’updater mais pas du lancement, cherchez un argument qui démarre l’UI. Si la politique l’autorise, désactivez la tâche et confirmez que l’application ne la recrée pas.
Tâche 9 : Désactiver une tâche planifiée (réversible)
cr0x@server:~$ powershell -NoProfile -Command "Disable-ScheduledTask -TaskName 'Teams Update Task' -TaskPath '\Microsoft\Teams\' | Out-Null; (Get-ScheduledTask -TaskName 'Teams Update Task' -TaskPath '\Microsoft\Teams\').State"
Disabled
Ce que ça signifie : La tâche est désactivée. Elle ne s’exécutera pas selon ses déclencheurs.
Décision : Redémarrez et confirmez. Si la tâche se réactive, c’est généralement la GPO/MDM ou l’updater qui s’exécute avec des droits élevés ailleurs.
Tâche 10 : Trouver les services en démarrage automatique qui semblent appartenir à un fournisseur
cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_Service | Where-Object { $_.StartMode -eq 'Auto' } | Select-Object Name,StartName,State,PathName | Sort-Object Name | Select-Object -First 8"
Name StartName State PathName
---- --------- ----- --------
BITS LocalSystem Running C:\Windows\System32\svchost.exe -k netsvcs -p
VendorAgent LocalSystem Running "C:\Program Files\Vendor\Agent\agentservice.exe"
VendorUpdater LocalSystem Running "C:\Program Files\Vendor\Updater\updater.exe" /service
wuauserv LocalSystem Running C:\Windows\system32\svchost.exe -k netsvcs -p
Ce que ça signifie : Les services dont le chemin pointe vers un fournisseur peuvent être légitimes (sécurité/gestion) ou du « marketing toujours‑allumé ».
Décision : Si vous désactivez un service, documentez‑le et sachez ce qui en dépend. Ne devinez pas sur des endpoints de production utilisés par des cadres cinq minutes avant une réunion.
Tâche 11 : Désactiver le démarrage automatique d’un service (procédez prudemment)
cr0x@server:~$ powershell -NoProfile -Command "Set-Service -Name 'VendorUpdater' -StartupType Disabled; Get-Service -Name 'VendorUpdater' | Select Name,Status,StartType"
Name Status StartType
---- ------ ---------
VendorUpdater Running Disabled
Ce que ça signifie : StartupType est Disabled, mais le service tourne encore pour l’instant.
Décision : Si vous voulez l’arrêter immédiatement, arrêtez‑le explicitement (tâche suivante). Sur un serveur, vérifiez les fenêtres de changement et les services dépendants avant d’agir.
Tâche 12 : Arrêter le service maintenant et vérifier qu’il reste arrêté
cr0x@server:~$ powershell -NoProfile -Command "Stop-Service -Name 'VendorUpdater' -Force; Get-Service -Name 'VendorUpdater' | Select Name,Status,StartType"
Name Status StartType
---- ------ ---------
VendorUpdater Stopped Disabled
Ce que ça signifie : Il est arrêté et ne redémarrera pas automatiquement via le gestionnaire de services.
Décision : Si le processus réapparaît quand même, quelque chose d’autre le lance : une tâche planifiée, un autre service, ou un auto‑réparateur de l’application.
Tâche 13 : Vérifier si une GPO applique des scripts de démarrage/logon
cr0x@server:~$ powershell -NoProfile -Command "gpresult /r | Select-String -Pattern 'Logon Scripts|Startup Scripts|Applied Group Policy Objects' -Context 0,3"
Applied Group Policy Objects
-----------------------------
Corp-Workstation-Baseline
Corp-App-Deployment
Logon Scripts
--------------
\domain\netlogon\corp-logon.ps1
Ce que ça signifie : Des scripts de logon existent. Ils peuvent ajouter des clés Run, créer des tâches planifiées, ou déposer des raccourcis de démarrage.
Décision : Si la politique est impliquée, arrêtez les bidouilles locales. Escaladez vers le propriétaire de la baseline et corrigez à la source.
Tâche 14 : Forcer un rafraîchissement des stratégies (pour tester si votre changement est reverté)
cr0x@server:~$ powershell -NoProfile -Command "gpupdate /force"
Updating policy...
Computer Policy update has completed successfully.
User Policy update has completed successfully.
Ce que ça signifie : Les politiques ont été réappliquées. Si votre réglage « se défait » maintenant, vous avez prouvé que la politique en est propriétaire.
Décision : Soit ajustez la configuration GPO/MDM, soit acceptez que cet élément de démarrage soit imposé et concentrez‑vous sur son impact performance.
Tâche 15 : Vérifier ce qui a réellement démarré depuis le dernier boot (contrôle des processus)
cr0x@server:~$ powershell -NoProfile -Command "Get-Process | Sort-Object StartTime -Descending | Select-Object -First 10 Name,Id,StartTime"
Name Id StartTime
---- -- ---------
Teams 884 02/05/2026 09:21:40
OneDrive 910 02/05/2026 09:21:35
VendorAgent 622 02/05/2026 09:20:58
explorer 4020 02/05/2026 09:20:40
Ce que ça signifie : Vous regardez le comportement observé, pas l’intention de configuration.
Décision : Si l’application démarre encore, vous avez manqué un mécanisme ou quelque chose l’a réactivée. Retournez aux tâches/svc/registre.
Tâche 16 : Remonter le fichier/commande responsable d’un raccourci de démarrage
cr0x@server:~$ powershell -NoProfile -Command "$lnk=Join-Path $env:APPDATA 'Microsoft\Windows\Start Menu\Programs\Startup\Teams.lnk'; $w=New-Object -ComObject WScript.Shell; $s=$w.CreateShortcut($lnk); $s.TargetPath; $s.Arguments"
C:\Users\alice\AppData\Local\Microsoft\Teams\current\Teams.exe
--processStart "Teams.exe"
Ce que ça signifie : Vous avez résolu le raccourci vers le binaire réel et ses arguments.
Décision : Utilisez cela pour confirmer que vous désactivez la bonne cible. Si la cible est un updater qui lance l’app, votre correctif doit aussi traiter l’updater.
Tâche 17 : Détecter les surprises « RunOnce » (entrées une fois qui comptent encore)
cr0x@server:~$ powershell -NoProfile -Command "Get-ItemProperty -Path 'HKLM:\Software\Microsoft\Windows\CurrentVersion\RunOnce' -ErrorAction SilentlyContinue | Select-Object * -ExcludeProperty PS*"
UpdateFinalize : "C:\Program Files\Vendor\Updater\finalize.exe" /boot
Ce que ça signifie : Les entrées RunOnce sont censées s’exécuter puis disparaître, mais elles peuvent réapparaître si un updater continue de les replanifier.
Décision : Si la performance au démarrage pose problème, ce sont des suspects de choix. Ne supprimez pas à l’aveugle ; corrigez le comportement de l’updater s’il boucle.
Trois mini-récits d’entreprise issus du terrain
Mini-récit 1 : L’incident causé par une mauvaise hypothèse (le Gestionnaire des tâches n’est pas la vérité)
Une équipe d’ingénierie desktop a reçu une vague de tickets : « Le démarrage du portable est lent, Teams s’ouvre tout le temps, CPU saturé à la connexion. » Ils ont fait ce que tout le monde fait d’abord — ils ont dit aux utilisateurs de désactiver Teams dans l’onglet Démarrage du Gestionnaire des tâches. Les tickets se sont calmés, puis sont revenus. Même symptôme, mêmes utilisateurs, mêmes machines.
La mauvaise hypothèse était subtile : ils ont supposé que l’onglet Démarrage montrait tout. Ce n’était pas le cas. Sur ces images, le basculement UI désactivait une entrée Run dans le registre, mais une tâche planifiée restait. La tâche s’exécutait au logon en tant que SYSTEM, lançait un updater, et l’updater lançait quand même le processus UI.
Pire : la tâche était déployée par une politique de baseline, donc même quand quelqu’un la désactivait localement, elle se réactivait au prochain rafraîchissement de la stratégie. Cela créait le pattern « ça ne tient pas » qui érode la confiance. Les utilisateurs ont commencé à traiter les conseils IT comme des bulletins météo.
La correction n’a pas été héroïque. Ils ont audité les tâches de logon/démarrage, identifié la tâche et l’action exactes, et changé la baseline pour exécuter l’updater sans lancer l’UI au login. L’important : ils ont ajouté de la vérification — contrôles de processus post‑login et tests de rafraîchissement de politique — pour prouver que c’était résolu.
Mini-récit 2 : L’optimisation qui a échoué (désactiver le service d’updater)
Une autre organisation avait une initiative de performance : réduire le temps de boot, réduire les services en arrière‑plan, « rendre les portables plus rapides ». Un ingénieur bien intentionné a trouvé un service updater fournisseur en mode Automatic. Il semblait non essentiel, alors ils l’ont désactivé sur un groupe pilote.
Le temps de démarrage s’est amélioré. Les gens ont applaudi. Puis, quelques semaines plus tard, une mise à jour de sécurité critique pour le client fournisseur a tardé à arriver sur les machines pilotes. Le service updater n’était pas juste « agréable à avoir » — c’était la voie de distribution pour les correctifs et les configurations.
Le retour de bâton n’était pas que désactiver un service soit intrinsèquement mauvais. C’était qu’ils ont optimisé une métrique (vitesse de démarrage) sans préserver la capacité du système à se maintenir. En termes SRE : ils ont amélioré la latence en réduisant discrètement la fiabilité.
Le plan de récupération a été un compromis : mettre le service en Manual (ou Automatic (Delayed Start) quand possible), empêcher le lancement d’UI au login, et conserver les mécanismes de mise à jour. Ils ont aussi ajouté du monitoring : les machines sans mises à jour étaient signalées. Vous ne voulez pas découvrir « nous avons désactivé la distribution des patches » en lisant un rapport post‑incident.
Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (sauvegarde + désactivation contrôlée)
Un poste du service finance lançait un ancien outil de reporting à chaque connexion. Il mettait une minute à se charger et encombrait les partages réseau dans le flux d’authentification. Au moment de la clôture mensuelle, cette minute se transformait en utilisateurs en colère très vite.
Un ingénieur a fait la chose la moins glamour imaginable : avant de toucher quoi que ce soit, il a exporté les clés de registre pertinentes et enregistré les définitions des tâches planifiées actuelles. Il a ensuite désactivé les entrées de démarrage mécanisme par mécanisme, redémarrant et vérifiant après chaque changement. Lent, méthodique, agaçamment correct.
Deux jours plus tard, une mise à jour a réintroduit une clé Run. Parce qu’ils disposaient d’un instantané baseline, ils ont pu prouver ce qui avait changé et quand. Ils n’ont pas bataillé avec le fournisseur ; ils ont présenté des preuves : « Votre updater a réintroduit cet autostart lors de la mise à jour. » Cela a changé la conversation.
La correction finale a tenu : supprimer le déclencheur de logon, garder la tâche d’update, et faire respecter « pas de lancement auto de l’UI » via configuration. La clôture mensuelle est redevenue ennuyeuse. L’ennuyeux est une caractéristique sous‑estimée.
Listes de contrôle / plan étape par étape qui ne pourrit pas
Checklist A : Machine unique, vous voulez juste que l’app ne se lance plus
- Inventorier l’état actuel
- Dossiers de démarrage (par utilisateur et tous les utilisateurs)
- Clés HKCU et HKLM Run
- Tâches planifiées avec déclencheurs Logon/Startup
- Services avec chemins fournisseur, en Auto
- Sauvegarder
- Exporter les clés Run vers des .reg
- Enregistrer les noms/chemins des tâches et les types de démarrage des services
- Désactiver d’abord l’endroit le plus précis
- Supprimer une valeur Run spécifique
- Désactiver la tâche planifiée précise qui lance l’UI
- Supprimer le raccourci de démarrage
- Redémarrer et vérifier
- Confirmer que le processus ne tourne pas après la connexion
- Confirmer que l’entrée ne réapparaît pas
- Déclencher les forces de réversion
- Exécuter un rafraîchissement de stratégie
- Laisser l’application se mettre à jour (ou exécuter son updater) et revérifier
Checklist B : Flotte d’entreprise, il faut que ça tienne à travers les mises à jour et les utilisateurs
- Décidez de la propriété d’abord : changement local vs politique baseline vs configuration d’application.
- Trouvez le mécanisme de démarrage canonique : tâche/service/Run key créé par l’installateur ou l’outil de management.
- Privilégiez « désactiver le lancement automatique de l’UI » plutôt que « casser la distribution des updates ».
- Implémentez centralement : déploiement de tâche planifiée, préférence registre, ou réglage MDM — selon ce que votre org utilise uniformément.
- Ajoutez une validation : un contrôle de conformité qui vérifie que l’entrée d’autostart est absente/désactivée et que le processus ne tourne pas après le login.
- Documentez la restauration : ce qu’il faut réactiver et quels effets secondaires attendre.
Blague n°2 (courte et pertinente) : Si vous désactivez la mauvaise entrée de démarrage, Windows vous enseignera l’humilité au prochain reboot — gratuitement.
Erreurs courantes : symptôme → cause racine → correction
1) Symptom : « Désactivé dans le Gestionnaire des tâches, mais ça se lance encore »
Cause racine : Une tâche planifiée ou un service le lance ; le Gestionnaire des tâches n’a togglé qu’une surface.
Correction : Énumérez les tâches avec déclencheurs Logon/Startup, inspectez l’action de la tâche, désactivez ou ajustez la tâche spécifique. Puis vérifiez les services qui pourraient engendrer le processus UI.
2) Symptom : « Ça s’arrête pour moi, mais pas pour les autres utilisateurs »
Cause racine : Vous avez changé HKCU ou le dossier de démarrage par utilisateur seulement.
Correction : Vérifiez HKLM Run et le dossier All Users Startup, plus les tâches planifiées déclenchées pour « Any user ». Appliquez la correction au niveau machine si approprié.
3) Symptom : « Ça revient après une mise à jour »
Cause racine : L’auto‑réparation de l’application réajoute des Run keys/tâches ; l’updater s’exécute avec des droits élevés.
Correction : Désactivez le comportement « lancer au login » spécifique (souvent une tâche) en laissant les mécanismes de mise à jour. Si vous devez supprimer des clés, script‑ez la suppression et exécutez‑la après les mises à jour via l’outil de management.
4) Symptom : « J’ai désactivé le service, maintenant l’app casse d’une façon étrange »
Cause racine : Vous avez désactivé un composant partagé (update/telemetry/auth broker) dont dépend l’application.
Correction : Réactivez le service et changez plutôt le chemin d’autostart de l’UI. Si le service pose problème, mettez‑le en Manual ou Delayed Start et validez le comportement de l’application.
5) Symptom : « Je n’arrive pas à le supprimer ; accès refusé »
Cause racine : Les clés HKLM, les tâches système ou les services requièrent des droits admin. Ou la politique l’applique.
Correction : Élevez correctement vos droits ; si l’élément réapparaît après gpupdate /force, il est contrôlé par la politique. Corrigez centralement, pas localement.
6) Symptom : « Aucune entrée de démarrage trouvée, mais l’app s’ouvre quand même »
Cause racine : L’app utilise un déclencheur non évident : tâche planifiée basée sur un événement, extension du shell Explorer, ou une autre app la lance.
Correction : Inspectez les tâches planifiées au‑delà des simples déclencheurs Logon/Startup, et identifiez quel processus est le parent lanceur (nécessite des outils plus poussés). Commencez par chercher dans la bibliothèque du Planificateur de tâches les noms éditeurs.
7) Symptom : « Le démarrage est lent ; rien d’évident ne démarre »
Cause racine : Services et drivers en arrière‑plan, pas des apps utilisateur. Ou des tâches s’exécutent pendant le démarrage avant l’affichage de la session.
Correction : Auditez les services Automatic et les tâches de démarrage. Ne vous focalisez pas uniquement sur les autostarts visibles par l’utilisateur.
FAQ (les questions posées cinq minutes avant une fenêtre de changement)
1) L’onglet Démarrage du Gestionnaire des tâches suffit‑il ?
Non. C’est une tranche pratique du problème. Les tâches planifiées et les services contournent souvent cet onglet, et la politique peut l’outrepasser.
2) Quelle est la chose la plus sûre à désactiver en premier ?
L’entrée précise qui lance l’UI au login : une valeur Run par utilisateur ou une tâche planifiée déclenchée au logon. Évitez de désactiver les services de mise à jour sans comprendre les conséquences sur le patching.
3) Comment savoir si le démarrage est par utilisateur ou machine ?
Vérifiez où se trouve l’entrée. HKCU et le dossier de démarrage utilisateur affectent un seul utilisateur. HKLM, All‑Users Startup, les services et de nombreuses tâches affectent tout le monde.
4) Pourquoi ça revient après que j’ai supprimé une valeur de registre ?
Parce que quelque chose la réécrit : une tâche d’updater, un service, ou une politique. Prouvez la propriété en désactivant la tâche et en forçant un rafraîchissement des stratégies pour voir ce qui se rétablit.
5) Dois‑je supprimer la clé Run entière pour « nettoyer » ?
Non. C’est comme casser des composants légitimes et créer un bazar de dépannage. Supprimez uniquement la valeur nommée spécifique, et sauvegardez d’abord.
6) Qu’en est‑il des clés RunOnce — dois‑je les effacer ?
Seulement si elles sont bloquées en boucle et que vous avez confirmé que l’updater sous‑jacent se comporte mal. RunOnce est souvent légitime pour les installateurs et les finalisations post‑mise à jour.
7) Comment gérer les appareils d’entreprise où la politique réactive tout ?
Arrêtez de lutter localement. Identifiez l’artéfact GPO/MDM (tâche, préférence registre, script) et modifiez‑le centralement. Les bidouilles locales sont temporaires et créent des flottes inconsistantes.
8) Puis‑je « désactiver l’autostart » tout en laissant l’app s’exécuter au besoin ?
Oui. Désactiver l’autostart n’équivaut pas à désinstaller l’app. L’objectif est d’arrêter les chemins de lancement automatiques, pas de supprimer les binaires — à moins que vous ne retirez l’app.
9) Si je désactive une tâche planifiée, quelque chose peut‑il se casser ?
Oui. Certaines tâches assurent la distribution des updates ou des jobs de maintenance. Inspectez l’action de la tâche d’abord. Si elle lance l’UI au logon, désactivez cela ; conservez les tâches purement d’update si possible.
10) Quelle est la méthode la plus « collante » ?
La méthode la plus tenace est celle qui correspond au propriétaire. Si l’app utilise une tâche planifiée, modifiez ou désactivez cette tâche. Si la politique IT la déploie, changez la politique. Sinon vous jouez au Whac‑a‑mole.
Conclusion : prochaines étapes qui réduisent vraiment le bruit
Si vous voulez un contrôle du démarrage qui tient, arrêtez de le traiter comme un simple interrupteur. Traitez‑le comme un petit problème de fiabilité : entrées multiples, contrôleurs multiples, et beaucoup d’occasions de réversion silencieuse.
Faites ceci ensuite, dans l’ordre :
- Effectuez un inventaire : dossiers de démarrage, clés HKCU/HKLM Run, tâches planifiées, et services Automatic.
- Sauvegardez l’état (exportez les clés Run ; enregistrez tâches/services).
- Désactivez le mécanisme exact qui lance l’app, en commençant par les tâches planifiées et les valeurs Run.
- Redémarrez et vérifiez en observant les processus, pas seulement la configuration.
- Forcez un rafraîchissement des politiques et attendez un cycle de mise à jour — puis vérifiez à nouveau.
Quand ça « ne tient pas », ce n’est pas un échec. C’est de l’information. Cela vous indique qui possède le comportement : l’application, l’updater, ou le moteur de politique. Une fois que vous connaissez le propriétaire, la solution devient ennuyeuse. Et l’ennuyeux est ce qui maintient la production.