Pourquoi un logiciel ne fonctionne-t-il pas sans installation ? Guide visuel : comment les applications s’intègrent au système d’exploitation

Si vous utilisez un PC ou un smartphone, vous vous êtes sans doute heurté plus d’une fois à ces petites énigmes du quotidien.

• Slack et VS Code ne fonctionnent qu’après installation, alors que Gmail et Google Docs s’exécutent dès qu’on ouvre une URL ─ d’où vient cette différence ?
• Le monde regorge de commandes « install » ─ pip (Python), npm (Node.js), brew (Mac), apt (Linux), winget (Windows). Que font-elles réellement, toutes ces commandes ?
• Pourquoi faut-il saisir son mot de passe administrateur à chaque installation de logiciel ?
• Sur macOS, on glisse en général un fichier .app dans un dossier et l’affaire est réglée, tandis que les installateurs .exe de Windows enchaînent les boîtes de dialogue. Pourquoi cet écart ?

« Installation » est un mot unique qui recouvre des sensations très différentes, ce qui rend la chose difficile à résumer. Pourtant, dès qu’on remonte à la racine, tout converge vers la même réponse.

Pour qu’un logiciel s’exécute, il doit se présenter officiellement à l’OS (Windows, macOS, Linux, etc.) ─ « Bonjour, une nouvelle application emménage » ─ et lui serrer la main.

« Installation » n’est que le nom donné à cette cérémonie de poignée de main. Dans cet article, nous allons décortiquer :

• Ce que contient réellement un fichier exécutable (.exe / .app / .deb)
• Pourquoi les programmes ne peuvent pas tourner seuls et réclament toujours l’aide de l’OS
• Ce que la boîte noire « installation » fait concrètement en coulisses
• Pourquoi les univers « sans installation » (applications web, applications portables, conteneurs) peuvent tout simplement exister

Nous avancerons pas à pas, schémas à l’appui, sans présupposer aucune connaissance préalable.

1. Ce que sont réellement les programmes ─ les exécutables comme instructions destinées à l’OS et au CPU

Que contient exactement ce « paquet » .exe, .app ou .deb que vous venez de télécharger ? Une fois qu’on l’a ouvert, il devient évident pourquoi un programme ne peut pas s’exécuter tout seul.

1-1. Un exécutable n’est qu’une suite d’octets ─ mais des octets dans un ordre très précis

Si vous jetez un œil au contenu d’un exécutable, vous ne voyez qu’un long flot de zéros et de uns (du binaire). Dans un éditeur de texte, c’est totalement illisible. Mais l’ordre de ces octets obéit à des règles strictes, et quand l’OS les lit, le sens émerge : « le corps du programme commence ici », « cette zone contient les données », « cette section liste les bibliothèques externes », et ainsi de suite.

Cette structure lisible par l’OS s’appelle un format de fichier exécutable. Chaque OS majeur en utilise un parmi trois, et tous les PC du monde reposent sur l’un d’entre eux.

Voilà pourquoi, quand un .exe Windows refuse de tourner sur un Mac, il n’y a aucune malveillance derrière : l’OS ne parle tout simplement pas le même dialecte de format d’instructions. C’est un peu comme envoyer une lettre rédigée en japonais à un lecteur francophone : il voit bien les caractères, mais il ne peut pas en suivre le sens.

1-2. Les quatre grandes parties d’un exécutable

Les trois formats diffèrent dans le détail, mais leur structure d’ensemble se ressemble. En les découpant en quatre « pièces », on se les représente bien plus facilement.

┌─────────────────────────────────────┐
│ En-tête                             │ ← page de garde lue en premier par l'OS (« ELF v1.0 », « 64 bits », OS cible)
├─────────────────────────────────────┤
│ Code (.text)                        │ ← les instructions CPU elles-mêmes
├─────────────────────────────────────┤
│ Données (.data / .rodata)           │ ← chaînes, constantes, ressources embarquées
├─────────────────────────────────────┤
│ Symboles / infos de liaison         │ ← liste des « bibliothèques externes et fonctions à appeler »
└─────────────────────────────────────┘

• L’en-tête est la page de garde. L’OS la lit en premier et décide « est-ce vraiment un type de fichier que je peux exécuter ? »
• Le code contient les véritables instructions CPU ─ add, mov, jmp, etc.
• Les données stockent la matière première du programme : chaînes de texte, valeurs numériques par défaut, ressources image.
• Les symboles / infos de liaison forment une « liste de courses des pièces manquantes » ─ « je veux appeler printf ici, branchez-le pour moi », signale-t-elle à l’OS et au chargeur (loader).

Vous voyez le tableau ? Un exécutable n’est pas un produit fini. C’est un sac qui contient un plan de montage + de la matière première + un bon de commande. L’OS lit les instructions, transmet le code au CPU et raccorde les pièces manquantes (les bibliothèques partagées) pour que tout fonctionne réellement.

2. Les programmes ne tournent jamais seuls ─ le dialogue permanent avec l’OS

Comme l’a montré le §1, un exécutable transporte un « bon de commande ». Où passe-t-il sa commande ? Auprès de l’OS et de ses bibliothèques standards. Chaque fois qu’une application affiche un caractère à l’écran, ouvre un fichier ou échange avec le réseau, elle ne fait pas le travail elle-même ─ elle demande poliment à l’OS de s’en charger.

2-1. La pile à quatre étages : application → bibliothèque standard → noyau → matériel

Schématiquement, l’intérieur d’un PC s’empile ainsi.

┌─────────────────────────────┐   ← Slack, VS Code, les applications que vous lancez
│   Application                │
├─────────────────────────────┤
│   Bibliothèque standard      │   ← bibliothèque standard C, .NET, libc, Foundation, etc.
│   (runtime du langage)       │      Couche de traduction entre application et OS
├─────────────────────────────┤
│   Noyau (kernel) de l'OS     │   ← noyau Windows, noyau Linux, Darwin
│                              │      Maître de l'écran, des fichiers, du réseau, de la mémoire
├─────────────────────────────┤
│   Matériel                   │   ← CPU, mémoire, SSD, GPU, carte réseau
└─────────────────────────────┘

Quand une application veut « afficher « Hello » à l’écran », elle n’envoie pas de signaux directement au moniteur. C’est une course de relais qui se déroule :

1. L’application appelle une fonction comme printf("Hello")
2. La bibliothèque standard (libc en C, BCL en .NET) prépare une requête à l’OS pour « afficher à l’écran »
3. Elle transmet cette requête au noyau de l’OS ─ ce passage de relais s’appelle un appel système (un « bon de commande » officiel adressé par l’application à l’OS)
4. Le noyau, via le pilote d’affichage, dit au matériel quoi dessiner, et les caractères apparaissent

Autrement dit, les applications sont écrites dès le départ en partant du principe que l’OS leur viendra en aide. Il n’existe pas d’exécutable capable de tourner sans le concours d’un OS. Voilà la raison profonde pour laquelle « on installe une application pour un OS donné » est même un concept.

2-2. Les appels système ─ les « bons de commande » officiels adressés à l’OS

Un appel système (le guichet dédié où les applications disent « s’il vous plaît, faites ceci » à l’OS) demande typiquement :

Chacune de ces tâches est un travail que l’application ne peut pas, ou n’a pas le droit de, faire seule ─ elle s’en remet donc à l’OS. Sans son aide, une application ne peut même pas afficher un seul caractère à l’écran.

3. [Cœur du sujet] Ce que fait réellement « l’installation » en coulisses

À ce stade, on sait qu’une « application ne peut pas tourner sans l’aide de l’OS ». L’installation devient alors facile à résumer : c’est le terme générique qui désigne tout le travail préparatoire chargé d’organiser la relation entre l’application et l’OS. Quasi tous les installateurs du monde (.msi, .pkg, .dmg, .deb, .rpm, le glisser-déposer d’un .app sur macOS, le bouton « Installer » du Microsoft Store, etc.) enchaînent les six phases suivantes.

3-1. Les six phases d’un installateur

Chaque phase prend de quelques centaines de millisecondes à plusieurs dizaines de secondes ; leur somme correspond au « temps d’attente d’installation » que vous percevez.

1. 1Vérification de la signatureVérifie que le fichier vient « bien d’un auteur légitime » (voyez cela comme un contrôle du sceau d’authenticité). Sur Windows c’est Authenticode, sur Mac Gatekeeper, sur Linux la signature GPG des paquets.
2. 2ExtractionDécompresse le sac unique (l’installateur) en binaire principal, bibliothèques annexes, fichiers de configuration, documentation, etc. À ce stade, on se contente de « sortir les matériaux ».
3. 3PlacementDéplace les fichiers extraits vers les emplacements standards de l’OS. Sur Windows c’est C:\Program Files\, sur Mac /Applications/, sur Linux /usr/lib/ et /usr/bin/.
4. 4EnregistrementInscrit le nom de l’application dans le « carnet d’adresses » de l’OS. Windows écrit dans le registre (le carnet géant où l’OS conserve ses réglages), Mac dépose des fichiers plist, Linux place un .desktop.
5. 5IntégrationAjoute des icônes au menu Démarrer / au Launchpad / au menu des applications, et associe l’application aux extensions de fichier concernées (.txt, .psd, …).
6. 6Configuration post-installationEnregistre les éventuels services d’arrière-plan, construit les caches de premier lancement, ajuste le PATH, crée les raccourcis, puis fait le ménage des fichiers temporaires.

Pour mémoriser : vérifier → extraire → placer → enregistrer → intégrer → finaliser. Tout installateur déroule ces six étapes pour passer du « téléchargé » au « prêt à l’emploi ».

3-2. Avant / Après ─ le système de fichiers change à vue d’œil

Si les « six phases » vous paraissent encore abstraites, comparer le disque avant et après l’installation rend les choses immédiatement palpables.

~/Downloads/
└── SuperApp-1.2.3.exe   ← un seul sac

C:\Program Files\SuperApp\
├── SuperApp.exe                ← binaire principal
├── core.dll, render.dll, ...   ← pièces détachées (bibliothèques partagées)
└── resources\                  ← images, traductions

C:\Users\moi\AppData\Roaming\SuperApp\
└── settings.json               ← réglages utilisateur

Registre HKLM\Software\SuperApp
├── InstallPath = "C:\Program Files\SuperApp"
└── Version = "1.2.3"

Menu Démarrer → SuperApp (raccourci)

Comme vous le voyez, l’installation est l’acte combiné de « répartir un même .exe dans les bons dossiers + en informer l’OS ». Ce n’est pas que « le double-clic n’exécute rien » ─ c’est plutôt que dans les secondes ou minutes qui suivent ce double-clic, une grande quantité de configuration au niveau OS se met en place. Voilà le modèle mental le plus juste.

4. Les dépendances ─ pourquoi un exécutable ne tient pas debout tout seul

« Ce n’est qu’une seule application, pourquoi y a-t-il des centaines de fichiers ? » La réponse se trouve dans cette section. Le concept clé est celui des bibliothèques partagées (boîtes à pièces détachées que de nombreuses applications viennent emprunter).

4-1. Qu’est-ce qu’une bibliothèque partagée ?

« Enregistrer cette image en JPEG » est le genre de fonctionnalité dont Photoshop, les extensions VS Code et Slack ont tous besoin à un moment ou un autre. Si chaque application embarquait sa propre copie :

• Le disque enfle sous le poids des pièces dupliquées
• Le moindre correctif de sécurité oblige à rééditer toutes les applications

Pour éviter cette douleur, l’OS propose un mécanisme qui rassemble les pièces communes dans un seul fichier et les « prête » à plusieurs applications. Voilà ce qu’est une bibliothèque partagée (extension .dll sur Windows, .dylib sur Mac, .so sur Linux).

                 ┌──────────────────────────┐
                 │      votre application     │
                 └──────────────────────────┘
                       │   │   │
        ┌──────────────┘   │   └──────────────┐
        ▼                  ▼                  ▼
   libjpeg.dll        libssl.dll         libcurl.dll
   (boîte JPEG)       (boîte chiffrement) (boîte HTTP)
        │                  │                  │
        └──────────────────┴──────────────────┘
                           ▼
                ┌──────────────────────┐
                │   API de l'OS (kernel) │
                └──────────────────────┘

Même si l’application en elle-même ne pèse que quelques Mo, en pratique elle s’appuie sur une poignée de ces « boîtes à pièces » que l’installateur dépose sur le disque en même temps que le binaire principal. C’est pour cela qu’« une seule application » peut occuper plusieurs centaines de Mo une fois installée.

4-2. L’enfer des DLL ─ quand les pièces partagées se chamaillent pour la version

Les bibliothèques partagées sont pratiques, mais elles ont un mode de défaillance célèbre : quand les versions ne s’alignent pas, tout part en vrille d’un coup. C’est le légendaire « enfer des DLL » (le chaos qui survient quand deux applications réclament des versions différentes d’une même boîte à pièces et finissent par se casser mutuellement).

   App A  ─→ requiert libfoo v1.0
   App B  ─→ requiert libfoo v2.0
                    │
                    ▼
        Une seule libfoo peut loger dans l'OS
        →  l'une des deux finira forcément par casser

Les systèmes d’exploitation modernes atténuent ce risque, chacun à sa manière :

• Windows : WinSxS (Side-by-Side) et les paquets type Microsoft.UI.Xaml permettent à plusieurs versions de coexister sous des noms de fichiers distincts
• macOS : encourage chaque .app à embarquer sa propre copie des .dylib nécessaires
• Linux : les gestionnaires de paquets (abordés plus loin) résolvent à votre place le graphe de dépendances

Et pourtant, quand vous déterrez un vieux logiciel et tombez sur l’erreur MSVCR100.dll not found, cet avertissement est l’ombre persistante de ce même problème.

5. L’intégration à l’OS ─ associations de fichiers, entrées de menu, démarrage automatique

Lors des phases 4 et 5 du §3 (enregistrement et intégration), l’installateur fait officiellement déclarer l’existence de l’application à l’OS. En regardant précisément « ce qui est écrit et où », côte à côte entre systèmes d’exploitation, les différences sautent aux yeux.

5-1. Ce qui est enregistré, OS par OS

« Les applications ont beau se ressembler en surface, le carnet dans lequel elles écrivent réellement diffère d’un OS à l’autre. » Une fois ce déclic acquis, plus rien d’étonnant à entendre « le logiciel tournait nickel sous Windows, mais sous macOS, on a l’impression de manipuler une autre bête ».

5-2. Pourquoi « poser simplement l’exécutable quelque part » ne suffit pas

Vous pouvez laisser un fichier comme notepad.exe dans Téléchargements et double-cliquer dessus ; techniquement, il se lancera. Mais vous ne profiterez pas d’expériences telles que :

• Le lancement rapide depuis le menu Démarrer
• Le double-clic sur un .txt qui l’ouvre automatiquement dans cette application
• La désinstallation en un clic depuis l’écran « Désinstaller un programme » de l’OS
• Les mises à jour automatiques qui tournent toutes seules
• La même icône qui revient après un redémarrage

Tout cela est le fruit de l’intégration OS. L’installation est devenue ce combo « placer des fichiers + les enregistrer auprès de l’OS » précisément pour rendre cette expérience possible.

6. Permissions et sécurité ─ pourquoi votre mot de passe administrateur est demandé

« Pourquoi me redemander mon mot de passe à chaque installation ? » Ce petit frottement est en réalité la preuve que le loquet de sécurité de l’OS fonctionne. Une fois la logique comprise, la question cesse d’être agaçante.

6-1. Zone système vs zone utilisateur

Le système de fichiers d’un OS se divise entre les emplacements qui exigent des droits administrateur pour écrire et ceux qui ne les exigent pas.

┌──────────────── Droits administrateur requis ──────────────┐
│  Windows : C:\Program Files\, C:\Windows\, HKLM\registre   │
│  macOS   : /Applications/, /Library/, /usr/local/          │
│  Linux   : /usr/, /etc/, /opt/                             │
└──────────────────────────────────────────────────────────────┘
┌──────────────── Droits utilisateur suffisants ─────────────┐
│  Windows : %USERPROFILE%\AppData, HKCU\registre            │
│  macOS   : ~/Library/, ~/Applications/                      │
│  Linux   : ~/.local/, ~/.config/                           │
└──────────────────────────────────────────────────────────────┘

Pendant la phase 3 (placement) du §3, l’installateur qui veut déposer l’application dans la zone système se voit stoppé par l’OS qui demande « êtes-vous sûr de vouloir cela ? ». Soit, très exactement :

• La boîte UAC de Windows (« Voulez-vous autoriser cette application à apporter des modifications à votre appareil ? »)
• L’invite de mot de passe de macOS
• La demande de mot de passe sudo sous Linux

Et le cas symétrique ─ « glisser un .app Mac dans son propre ~/Applications/ sans qu’on vous demande de mot de passe » ─ découle exactement de la même logique.

6-2. Vérification de signature ─ le contrôle du sceau d’authenticité

En plus des permissions, l’OS pré-vérifie aussi « cet installateur provient-il bien de l’auteur qu’il prétend être ? ». C’est la vérification de signature (le contrôle du « tampon / sceau » qui confirme que l’installateur est bien l’original d’un auteur légitime), et chaque OS a sa propre déclinaison :

Les avertissements du type « cette application provient d’un développeur non identifié » ou « cette application ne peut pas être ouverte car elle n’a pas pu être vérifiée » sont exactement le résultat de ces contrôles de signature. Un échec ne signifie pas automatiquement qu’il s’agit d’un logiciel malveillant ─ les petits développeurs indépendants se passent souvent de signature de code, faute de moyens pour payer les certificats ─ mais « ne rien lancer qui échoue au contrôle » reste l’attitude par défaut la plus sûre.

7. L’univers du « sans installation »

Jusqu’ici, nous avons posé « installation = poignée de main avec l’OS ». Si quelqu’un d’autre s’occupe de cette poignée de main à votre place, alors en principe vous n’avez plus rien à installer vous-même. Et concrètement, l’informatique moderne propose plusieurs façons de faire exactement cela. Voyons rapidement comment chacune s’en sort.

7-1. Les quatre approches d’un coup d’œil

7-2. Pourquoi chaque approche s’autorise le « sans installation »

Chacune expliquée en termes simples, avec une analogie accessible aux débutants.

• Application web : le véritable programme vit sur un serveur distant, pas sur votre PC. Votre PC, lui, ne fait que faire tourner un navigateur. Comme le navigateur a déjà serré la main de l’OS, les applications qui roulent par-dessus n’ont pas besoin de leur propre poignée de main (imaginez qu’on emprunte une table dans un restaurant).
• Application portable (imaginez toute l’application compressée sur une clé USB) : elle transporte toutes les pièces dont elle a besoin et évite de toucher au registre Windows ou aux plist, si bien que dézipper suffit. Le compromis : une taille plus importante et aucune intégration OS (pas d’entrées de menu, pas d’associations de fichiers).
• Conteneur (imaginez une petite pièce portable et étanche qui regroupe l’application avec les morceaux d’OS dont elle a besoin) : non seulement l’application, mais aussi les bibliothèques et la configuration qu’elle utilise sont entassées dans cette pièce et s’exécutent isolées de votre OS hôte. La poignée de main a lieu à l’intérieur de la pièce, si bien que presque rien n’est écrit dans votre PC réel. C’est précisément la commodité qui a fait de « livrer tout le runtime, pas juste le code » la norme de l’ère cloud.
• Gestionnaire de paquets (il automatise pour vous, à la place de l’OS, la routine d’« installation » que vous feriez à la main) : ça ressemble à du « sans installation », mais en réalité, il se contente de dérouler pour vous les six phases du §3 en une seule commande. Mieux vaut le voir comme une « installation, mais bien automatisée ». Pendant les quelques secondes d’un brew install nginx, la chorégraphie vérifier / extraire / placer / enregistrer se déroule derrière le rideau.

Vu sous cet angle, « ai-je besoin d’installer ou pas ? » se réduit à « qui s’occupe de la poignée de main avec l’OS à ma place ? ». Pour les applications web, c’est le navigateur ; pour les conteneurs, le moteur de conteneurs ; pour les gestionnaires de paquets, un script d’automatisation. Quelqu’un, quelque part, est toujours en train de serrer la main.

8. Le voir en pratique ─ commandes qui révèlent ce que l’installation a vraiment changé

Maintenant que la théorie est claire, ouvrons votre propre PC pour confirmer que « oui, des fichiers sont bel et bien ajoutés lors d’une installation ». Chaque OS dispose pour cela d’une ou deux lignes de commande.

8-1. Lister les applications / paquets installés

Commençons par afficher « ce qui est actuellement installé sur ce PC », OS par OS.

# Windows (PowerShell)
Get-Package | Select-Object Name, Version | Sort-Object Name

# macOS (applications installées via Homebrew)
brew list --versions

# Linux (Debian / Ubuntu)
dpkg -l | head -20

8-2. Inspecter les fichiers déposés par une application

Vous pouvez aussi zoomer sur un paquet précis et voir exactement quels fichiers son installateur a dispersés à travers le système.

# Linux (Debian / Ubuntu) ─ liste tous les fichiers déposés par le paquet git
dpkg -L git | head -20

# macOS ─ inspecter un paquet installé via le chemin .pkg officiel
pkgutil --pkg-info com.apple.pkg.CLTools_Executables

# Windows ─ lister les installations via les clés Uninstall du registre
Get-ItemProperty 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*' | Select-Object DisplayName, DisplayVersion

Vous verrez apparaître des entrées comme /usr/bin/git, /usr/share/man/man1/git.1.gz, /etc/bash_completion.d/git ─ autrement dit une seule application qui essaime à travers de nombreux endroits de l’OS. Réaliser à quel point « ce fichier unique téléchargé s’infiltre largement dans l’OS » est précisément ce qui rend l’installation tangible, et non plus magique.

Conclusion ─ quatre lignes pour tout résumer

Long article, mais son essence tient en quatre points.

• Une application ne peut pas tourner seule. Elle ne fonctionne qu’en empruntant l’OS et le matériel ─ d’où l’inévitable protocole de poignée de main avec l’OS.
• L’installation est la cérémonie qui exécute cette poignée de main ─ vérifier, extraire, placer, enregistrer, intégrer, finaliser, six phases dans l’ordre.
• Le mot de passe administrateur, c’est « êtes-vous sûr de vouloir écrire dans la zone système ? » La vérification de signature, c’est « est-ce bien l’œuvre d’un auteur légitime ? ».
• Web, portable, conteneur et gestionnaire de paquets ne sont que des « mandataires » pour la poignée de main ─ le « sans installation » ne tient que parce que quelqu’un, quelque part, a déjà serré la main.

Avec ces quatre points en tête, vous pouvez lire .exe, .app, .deb ou docker run à travers la même grille et comprendre ce qui se joue sous vos yeux.

Pour le socle côté réseau, voyez notre précédent article Qu’est-ce qu’une adresse IP ?. Combinez-le avec la « poignée de main entre OS et application » d’aujourd’hui, et vous obtenez la vision complète de la façon dont les données arrivent sur votre appareil et dont l’application qui s’y trouve fonctionne réellement. Pour pousser plus loin, Choisir le bon type numérique en SQL, également sur ce site, suit le même fil de « comment les données sont représentées à l’intérieur d’un programme ».

FAQ

Q1. Quelle est la différence entre une application portable et une application installée ?

R. Le binaire réel à l’intérieur est quasi identique ; ce qui diffère, c’est la présence ou non d’une intégration OS. Une copie installée déroule les six phases du §3 et « serre profondément la main » à l’OS : vous obtenez donc entrées dans le menu Démarrer, associations de fichiers, mises à jour automatiques, etc. Une copie portable, elle, s’arrête aux phases 1–2 (vérifier, extraire) plus le placement du dossier ─ elle saute délibérément l’inscription de son nom dans le carnet d’adresses de l’OS.

Q2. La désinstallation supprime-t-elle vraiment tout ?

R. L’essentiel disparaît, mais les réglages et les données utilisateur sont en général laissés sur place. Windows conserve la configuration sous C:\Users\<vous>\AppData\, Mac sous ~/Library/Application Support/<App>/, Linux sous ~/.config/<app>/ ─ et c’est volontaire, afin qu’une future réinstallation puisse retrouver vos préférences. Si vous voulez tout nettoyer, supprimez ces dossiers à la main ou utilisez un outil tel que AppCleaner (Mac) ou Bulk Crap Uninstaller (Windows).

Q3. Pourquoi le glisser-déposer fonctionne-t-il avec les bundles .app de macOS ?

R. Un .app n’est pas vraiment un « fichier » ─ c’est un dossier rempli de tout ce dont l’application a besoin (on parle de bundle). Le binaire principal, les pièces (.dylib), les ressources et Info.plist y sont tous regroupés, si bien que très peu d’écriture externe façon registre est nécessaire. Déposer le dossier dans /Applications/ suffit à l’OS pour le reconnaître. Les .exe de Windows peuvent eux aussi tourner en standalone, mais la convention Windows éparpille leurs réglages dans le registre, et un simple glisser ne suffit donc pas à laisser une installation propre.

Q4. Exécuter Docker, est-ce que ça compte comme « installer » ?

R. Pensez-y en deux couches. Docker lui-même (le moteur qui exécute les conteneurs) doit, lui, faire l’objet d’une installation native unique sur votre PC. Une fois en place, chaque application individuelle que vous lancez par-dessus vit à l’intérieur d’un conteneur (« petite pièce privée ») et n’est jamais écrite dans votre véritable OS. Les « applications qui paraissent sans installation » le sont précisément parce que le moteur Docker s’occupe à leur place de la poignée de main avec l’OS.

Q5. Peut-on installer un logiciel sans droits administrateur ?

R. Oui, tant que vous restez dans la zone utilisateur. Sur Windows, il existe des « installateurs utilisateur » qui déposent les fichiers sous %LOCALAPPDATA% (le « User Installer » de VS Code, par exemple) ; sur Mac, on peut glisser un .app dans ~/Applications/ ; sur Linux, on copie les binaires dans ~/.local/bin/ ou on utilise pipx install --user. Mais tout ce qui touche l’ensemble du système (installation d’un pilote, services d’arrière-plan permanents, dépôt de fichiers dans /usr/local/, etc.) doit, par nature, écrire dans la zone système et exige donc inévitablement les droits administrateur.