Infrastructure / Poste de travail / Admin By Request
Retirer les droits d’administrateur local, sans arrêter personne.
La question n’est pas de savoir s’il faut les retirer. C’est ce qui se passe le lendemain.Sur la plupart des parcs que nous découvrons, une partie des utilisateurs est administrateur local de sa machine — parfois tout le monde. Chacun sait que c’est un problème, et le projet ne démarre pas, parce que la vraie question n’est pas technique : c’est qui répondra aux demandes, en combien de temps, et ce qu’on fait à 19 h un vendredi.
Supprimer ces droits : trois raisons pour lesquelles ce n’est pas encore fait
Elles n’ont rien à voir avec le choix d’un logiciel. Ce sont elles qu’il faut traiter d’abord, et c’est pour cela que ce chantier traîne dans beaucoup d’entreprises alors que tout le monde est d’accord sur le principe.
Personne ne sait qui installe quoi
Les droits ont été donnés au fil des ans, pour de bonnes raisons ponctuelles, et plus personne n’a la liste. Retirer sans savoir, c’est arrêter quelqu’un dont vous ignoriez qu’il avait besoin d’installer un pilote chaque semaine.
On mesure avant de retirer quoi que ce soit.
La crainte d’un service informatique débordé
Si chaque installation devient un ticket, l’équipe passe ses journées à approuver des demandes. C’est la peur légitime qui bloque le projet, et elle se règle par la règle, pas par le produit : la plupart des demandes n’ont pas besoin d’un humain.
Ce qui est prévisible s’automatise, le reste se décide.
Personne ne veut être celui qui dit non
Retirer un droit à un directeur, à un ingénieur, à quelqu’un qui travaille la nuit, c’est un sujet politique avant d’être un sujet technique. Une règle écrite et la même pour tous vaut mieux qu’une décision au cas par cas que personne ne veut porter.
La règle protège aussi celui qui l’applique.
Ce qui se passe le lendemain
C’est la partie que les fiches produit ne décrivent pas, parce que ce n’est pas un problème de produit. Quatre situations arrivent dès la première semaine, et chacune se traite d’une façon différente. Les prévoir, c’est ce qui fait tenir le projet.
Une installation banale, en pleine journée
Un logiciel connu, un utilisateur connu, une machine à jour. La demande se traite sans personne : elle est approuvée automatiquement, le fichier est analysé avant de s’exécuter, et l’action est inscrite au journal.
C’est la grande majorité des demandes, et c’est ce qui décide si votre équipe est débordée ou non.
Un logiciel que personne ne connaît
Là, quelqu’un doit trancher. La demande arrive avec ce qu’il faut pour décider — qui, quoi, depuis quelle machine, et ce que l’analyse du fichier a donné — et non un message qui dit seulement « je voudrais installer ».
Ce qui se règle avec vous : qui décide, et en combien de temps il s’engage à répondre.
19 h, un vendredi, et personne ne répond
C’est le cas qui fait échouer les projets, parce qu’il produit le contournement définitif. La réponse n’est pas de laisser la porte ouverte : c’est une session à durée limitée, que l’utilisateur déclenche lui-même, avec une justification écrite et un journal complet de ce qui a été fait pendant.
Personne n’est bloqué, et rien n’est perdu de vue.
Ceux qui installent tous les jours
Les développeurs, les ingénieurs de test, les gens des ateliers. Leur retirer les droits comme aux autres, c’est en faire les premiers opposants au projet. Ils reçoivent une règle à eux, plus large, tracée de la même façon.
Une règle différente n’est pas une exception : elle est écrite, datée, et elle se relit.
Cet outil ne gère pas vos postes. Il gère qui a le droit d’y faire quoi.
Déployer les logiciels, appliquer les réglages, chiffrer les disques, garder les machines à jour : c’est le travail de la gestion du parc. Les deux se posent souvent dans le même mandat, mais ce sont deux sujets distincts, et l’un ne remplace pas l’autre.
Les questions qu’on nous pose
Dans cet ordre, à peu près à chaque fois. Les mécanismes décrits sont documentés par l’éditeur, et nous les revérifions avant chaque proposition.
| La question | La réponse |
|---|---|
| Faut-il monter un serveur ? | Non. Un client sur les postes, un portail en ligne. Rien à héberger chez vous, rien à publier vers l’extérieur, et donc rien de plus à maintenir ni à sauvegarder. |
| Que voit-on d’une installation ? | Qui, quoi, quand, depuis quelle machine, avec quelle justification, et ce que l’analyse du fichier a donné avant l’exécution. Le journal est la vraie livraison du projet — c’est lui qu’on relit après un incident, et il ne se reconstitue pas après coup. |
| Mes utilisateurs vont-ils attendre ? | Pour la grande majorité des demandes, non : elles se traitent sans intervention humaine. Ce qui décide du ressenti, c’est votre règle, pas le produit — et on l’écrit avec vous avant de déployer quoi que ce soit. |
| Et les Mac ? Et les serveurs ? | Le même mécanisme et le même journal sur Windows, sur macOS et sur les serveurs, depuis le même portail. C’est ce qui évite d’avoir trois façons de faire et trois endroits où chercher. |
| Est-ce que ça remplace notre antivirus ? | Non, et il ne faut pas le présenter ainsi. L’analyse porte sur le fichier qu’on s’apprête à exécuter avec des droits élevés, à ce moment-là. Votre protection habituelle reste en place et continue son travail. |
| Qu’est-ce qu’il ne fait pas ? | Il ne décide pas à votre place. Il applique la règle que vous écrivez : si elle est trop large, il trace proprement des droits que vous n’auriez pas dû donner. Il ne déploie pas vos logiciels, il ne remplace pas la gestion du parc, et il ne dira jamais si un logiciel inconnu mérite d’être installé chez vous — cette décision reste la vôtre. |
La dernière ligne porte sur le produit lui-même, pas sur ceux des autres. C’est le seul type d’aveu que nous nous autorisons : nous n’affirmons rien sur des solutions que nous ne fabriquons pas et dont les gammes changent chaque trimestre.
Comment se déroule un mandat
Quatre étapes. La première dure plus longtemps que les trois autres, et c’est normal : c’est elle qui décide si le reste se passe bien.
On mesure ce qui s’installe réellement
Le client est déposé en mode observation : personne ne perd de droit, et on enregistre pendant quelques semaines ce qui est réellement installé, par qui, et à quelle fréquence. Ce relevé remplace toutes les suppositions.
Presque toujours, il montre que la grande majorité des installations vient d’une petite liste de logiciels connus.
On écrit la règle avec vous
Ce qui passe seul, ce qui demande une décision, qui décide, en combien de temps, et ce qu’on fait en dehors des heures de bureau. C’est une discussion d’organisation, pas de paramétrage.
Elle tient en une page, elle est validée par la direction, et elle est la même pour tout le monde.
On retire les droits par vagues
Un service pilote d’abord, choisi avec vous, et on ne continue qu’après son bilan. Chaque vague suivante profite de ce que la précédente a appris — presque toujours des ajustements de la règle, pas du produit.
Les personnes concernées sont prévenues avant, avec la marche à suivre en trois lignes.
On relit le journal, et on resserre
Un mois après, le journal dit ce qui a réellement été demandé. C’est le moment de resserrer ce qui était trop large et d’élargir ce qui bloquait — sur des faits, pas sur des impressions.
Cette relecture se refait une fois par an : un parc bouge, et une règle posée une fois vieillit.
Ce qu’il faut savoir avant de vous engager
Trois points que nous posons nous-mêmes au premier rendez-vous. Chacun se règle ; aucun n’est un motif de renoncer.
Un outil ne remplace pas une décision
Si la règle écrite laisse presque tout passer, vous aurez un journal très complet de droits que vous n’auriez pas dû accorder. Le produit applique ; il ne tranche pas.
C’est pour cela que l’étape 02 existe et qu’elle est menée avec votre direction, pas avec votre seule informatique. Une page, validée, et le reste suit.
Quelques logiciels anciens exigent des droits en permanence
Un logiciel métier qui écrit dans un dossier système à chaque lancement ne fonctionnera pas avec un utilisateur ordinaire. C’est rare, mais cela existe, et cela se découvre à l’étape 01.
Ce qui se fait : on isole ces machines-là avec une règle propre, le reste du parc avance, et le remplacement du logiciel se planifie séparément — sans retenir tout le projet.
Les premières semaines demandent de la présence
Les demandes inhabituelles arrivent toutes au début. Si personne ne répond vite pendant cette période, les utilisateurs concluent que le nouveau système les gêne, et cette impression-là ne se rattrape pas.
Nous sommes présents sur la première vague, et l’engagement de délai est écrit avant de commencer. C’est prévu au budget dès le départ, pas ajouté après.
Les sujets voisins
Qui a le droit d’installer est une question ; qui a le droit d’entrer en est une autre, et elle se traite ailleurs.
La gestion des postes avec Intune
Déployer les logiciels, appliquer les réglages, chiffrer les disques, garder les machines à jour. Les deux chantiers se posent souvent dans le même mandat.
Lire la page IdentitéMicrosoft Entra ID
Les comptes d’administration de votre annuaire, ceux qui peuvent créer et donner des droits — un sujet distinct de l’administrateur d’une machine.
Lire la page DépartementInfrastructure et Cloud
Ce que fait l’équipe qui pose les postes, les serveurs, la messagerie et les annuaires : ce qu’elle prend en charge, et ce qu’elle ne fait pas.
Voir le départementCommençons par mesurer, sans rien retirer
Quelques semaines d’observation sur votre parc, personne ne perd de droit, et vous obtenez la liste de ce qui s’installe réellement chez vous. C’est ce relevé qui dit si le projet est simple ou non — et il vaut la discussion, même si vous décidez ensuite de ne rien faire.
Renens, Sion, Châtel-Saint-Denis. +41 21 806 37 15 — [email protected]