Le vrai sujet n'est pas d'installer, c'est de tenir
Déployer une application sur cinquante Mac est facile. Savoir six mois plus tard lesquels sont à jour, lesquels traînent une version vulnérable et pourquoi, c'est le travail réel.
Trois flux d'installation cohabitent sur un Mac d'entreprise, et les confondre est la source principale du désordre.
Le système, mis à jour par l'éditeur, pilotable par vos règles.
Les applications de la boutique, liées à un compte et parfois mises à jour toutes seules.
Les applications téléchargées ailleurs, chacune avec son propre mécanisme de mise à jour, ou aucun.
C'est la troisième catégorie qui produit les versions oubliées, et c'est aussi celle qui contient souvent les outils métier.
Une politique de mise à jour qui tient
Trois décisions, à écrire une fois.
Le délai avant une version majeure. Attendre quelques semaines est raisonnable : la compatibilité des outils métier n'est jamais garantie le jour de la sortie. Mais poser un plafond, sinon l'attente devient un report indéfini.
Le caractère obligatoire des correctifs de sécurité. Ceux-là ne se reportent pas. Une échéance courte, avec redémarrage imposé si nécessaire.
Le report accordé à l'utilisateur. Un ou deux reports possibles, puis l'installation se fait. Un système qui laisse reporter indéfiniment produit des machines jamais à jour, et un système qui ne laisse rien reporter produit des redémarrages en pleine réunion, donc des utilisateurs qui désactivent tout ce qu'ils peuvent.
Les applications métier
Préférez toujours le paquet fourni pour un déploiement géré quand il existe. Une application installée par glisser-déposer par l'utilisateur n'est pas inventoriée, donc pas mise à jour, donc invisible le jour d'une alerte de sécurité.
Le portail en libre-service change la relation : l'utilisateur installe ce dont il a besoin dans une liste validée, sans ticket et sans droits d'administration. Vous gardez l'inventaire, il gagne en autonomie.
Le point qui pique : les droits d'administration
La question revient toujours. Trois réponses possibles, et deux mauvaises.
Tout le monde administrateur : simple, et vous perdez toute maîtrise de ce qui est installé.
Personne administrateur, jamais : rigoureux, et vous créez un flux de tickets pour des gestes anodins, ce qui use le support et pousse au contournement.
Élévation temporaire et tracée : l'utilisateur obtient des droits pour une durée courte, la demande est enregistrée. C'est le seul modèle qui tient à la fois la sécurité et la charge de travail.
Vérifier, pas supposer
Un tableau mensuel de trois colonnes suffit : version du système par machine, applications hors du canal géré, et machines qui n'ont pas contacté le serveur depuis trente jours.
Cette dernière colonne est la plus utile de la flotte. Une machine muette est soit en panne, soit dans un tiroir, soit chez quelqu'un qui est parti. Les trois cas demandent une action.
À retenir
Trois flux d'installation, une politique écrite, des correctifs de sécurité non reportables. Déployez par le canal géré, sinon vous ne saurez jamais ce qui tourne. Et surveillez les machines qui ne parlent plus.