Modules
Script Builder
Script Builder prépare la collecte : profil, privacy, discovery, catalogue, cibles custom, clé collecteur et script Intune.
Rôle du module
Script Builder est l’atelier de préparation App Metering. Il centralise le choix du client, la configuration du profil, les applications à mesurer et le script à déployer. Il évite de surveiller tout le poste en forçant un ciblage explicite.
Le module doit être utilisé comme un outil de cadrage. Avant de générer un script, le MSP doit savoir quelle hypothèse il veut tester : Adobe sous-utilisé, Power BI Desktop réservé à trop d’utilisateurs, Autodesk installé hors profils techniques, ou applications métier coûteuses à rationaliser.
Sélection du client
Le client sélectionné détermine la clé collecteur, le profil, le catalogue contextualisé et les observations attendues. En scope “Tous les clients”, le MSP peut consulter globalement, mais la génération et le déploiement doivent rester attachés à un client précis.
Avant de sauvegarder, vérifiez toujours que le bon client est affiché. Une erreur de client au moment du déploiement peut envoyer les observations vers le mauvais contexte et obliger à tourner la clé.
Champs du profil
Le nom du profil doit être lisible par un technicien qui n’a pas participé au déploiement. Exemple : “Adobe Creative Cloud - pilote finance - 30 jours”. Le mode targeted mesure uniquement les applications choisies. Le mode discovery assisted aide à repérer des candidats, mais ne doit pas devenir une surveillance permanente.
Le niveau privacy règle la granularité. La fenêtre discovery définit combien de jours Wadyu garde le signal d’exploration. Les options “candidats discovery” et “process inconnus” doivent être activées uniquement si le client accepte une phase d’analyse plus ouverte.
Catalogue applicatif
Le catalogue contient les applications fréquentes : Adobe Acrobat Pro, Illustrator, InDesign, Photoshop, AutoCAD, Revit, Visio, Project, Power BI Desktop, Zoom ou outils métier. Ajouter une application au profil signifie qu’elle sera recherchée par le collecteur selon les process names configurés.
Une application catalogue doit rester compréhensible : nom commercial, éditeur, catégorie, process names, coût si connu et tags. Si plusieurs exécutables représentent une même suite, documentez-les ensemble pour éviter de sous-estimer l’usage.
Cibles custom
Les cibles custom servent aux applications absentes du catalogue : logiciels métier, outils techniques, applications internes, viewers spécialisés, clients lourds de finance ou CAO. Renseignez un nom clair, un éditeur, les process names et éventuellement les executable names.
Le coût mensuel est fortement recommandé. Sans coût, Wadyu peut mesurer l’usage mais ne peut pas produire un ROI convaincant. Pour les applications à coût annuel, convertissez en équivalent mensuel et notez l’hypothèse.
Clé collecteur et commande
La commande de déploiement contient l’URL collecteur et une clé client. Cette clé doit être traitée comme un secret. Si elle est exposée dans un ticket, un chat ou une capture publique, tournez-la et redéployez le script.
La rotation invalide les anciennes remontées. Planifiez-la lorsque les appareils peuvent recevoir la nouvelle Proactive Remediation. Surveillez les erreurs 401 ou 403 après rotation.
Sauvegarde et déploiement
Après chaque modification, sauvegardez le profil avant de copier le script. Si vous ajoutez une application mais ne sauvegardez pas, le prochain déploiement peut ne pas refléter le profil visible.
Le déploiement Intune doit d’abord viser un groupe pilote. Vérifiez ensuite la dernière utilisation du collecteur, le nombre d’observations et l’apparition des applications ciblées dans App Metering avant d’élargir.
Erreurs fréquentes
Aucune observation : application non lancée, mauvais groupe Intune, clé incorrecte, proxy bloquant l’URL, profil non sauvegardé ou process name incorrect. Trop d’observations : profil trop large, discovery permanent ou script lancé trop fréquemment.
Candidats discovery incompréhensibles : phase de découverte trop ouverte, postes pilotes non représentatifs ou absence de qualification des process. La découverte doit servir à enrichir le catalogue, pas à générer directement une facture d’économie.
Organisation du module
Script Builder est désormais organisé en trois sous-pages. Résumé sert de cockpit : client sélectionné, état du collecteur, nombre d’applications ciblées, discovery et disponibilité du script. Collecteur regroupe l’URL, le préfixe de clé, l’expiration, la dernière utilisation, les observations et la rotation de clé. Script Builder contient l’éditeur : profil, mode, privacy, catalogue, candidats discovery, cibles custom, copie du contenu et téléchargement du script Intune complet.
Le script téléchargé doit être celui envoyé dans Intune. Il embarque la configuration JSON et le collecteur, ce qui évite de reconstruire manuellement un wrapper. Avant déploiement, remplacez localement la clé si elle est affichée sous forme de placeholder et vérifiez le client sélectionné.