Guides pratiques

Collecteur Intune

Le collecteur Intune remonte les signaux d’usage applicatif vers Wadyu de manière ciblée, légère et compatible avec une approche privacy by design.

Rôle du collecteur

Le collecteur observe les applications explicitement ciblées par le profil Script Builder. Il ne lit pas les documents, ne capture pas l’écran et ne cherche pas à enregistrer l’activité utilisateur détaillée. Son rôle est de répondre à une question de gouvernance : une application coûteuse est-elle réellement utilisée ?

Le signal attendu est agrégé autour de l’application, du poste, de la fenêtre temporelle et du client. Cela suffit à établir un faisceau de preuves pour le ROI sans transformer Wadyu en outil de surveillance individuelle.

Déploiement recommandé

Utilisez Intune Proactive Remediation pour déployer le script sur un groupe pilote. Commencez avec un groupe restreint, vérifiez les retours, puis élargissez. Le script doit recevoir l’URL collecteur et la clé collecteur du client.

Ne déployez pas le collecteur globalement avant d’avoir validé le profil, la clé, la connectivité HTTPS, la rétention et le message de transparence client. Un déploiement trop large complique le dépannage et augmente les discussions conformité.

Clé collecteur

La clé collecteur identifie le client et autorise l’envoi de télémétrie. Elle doit être générée par client, protégée comme un secret opérationnel et tournée en cas d’exposition. Côté serveur, la valeur brute ne doit pas être conservée en clair.

Après rotation, les anciens postes continueront à échouer tant que la nouvelle commande Intune n’est pas déployée. Planifiez donc la rotation avec une fenêtre de propagation et surveillez les erreurs de collecte.

Fréquence et charge

La collecte doit rester légère. Les mesures doivent être espacées, ciblées et limitées aux applications définies. Un profil qui surveille trop d’exécutables réduit la lisibilité du résultat et peut être plus difficile à justifier.

Surveillez le taux d’observations par heure et les erreurs serveur. Une hausse soudaine peut indiquer un groupe Intune trop large, une boucle de script, une mauvaise configuration ou un déploiement répété.

Contrôles de fonctionnement

Après déploiement, vérifiez la dernière utilisation du collecteur, le nombre d’observations reçues, les erreurs éventuelles et l’apparition des applications ciblées dans App Metering. Un poste pilote doit produire un signal sans nécessiter de privilèges excessifs.

Si aucune donnée n’arrive, contrôlez l’URL HTTPS, la clé, les règles proxy, l’état Intune, la portée du groupe, les journaux de remédiation et le fait que les applications ciblées soient réellement lancées sur les postes.

Exécution manuelle et prérequis PowerShell

L’exécution manuelle sert à valider la chaîne avant d’attendre Intune : poste Windows, script PowerShell, endpoint collecteur, événement d’ingestion Wadyu puis affichage App Metering.

Prérequis : Windows 10 ou 11, PowerShell 5.1 ou 7, accès HTTPS sortant vers https://app.wadyu.tech/api/collect/app-usage, IP autorisée par la politique d’accès Wadyu, droits administrateur recommandés et au moins une application ciblée réellement lancée pendant la fenêtre d’observation.

Pour autoriser l’exécution uniquement dans la fenêtre PowerShell courante, ouvrez PowerShell en administrateur dans le dossier du script :

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -Force
Unblock-File .\wadyu-app-metering.ps1

Scope Process ne modifie pas durablement la politique de la machine. La permission disparaît à la fermeture de la fenêtre PowerShell.

Chemin recommandé : téléchargez le script généré depuis Wadyu, remplacez localement <collector-key> par la clé collecteur du client, puis lancez :

powershell.exe -ExecutionPolicy Bypass -File .\wadyu-app-metering.ps1

Le script généré embarque déjà l’URL collecteur et la configuration JSON du profil. Ne reconstruisez pas manuellement le wrapper sauf besoin de diagnostic avancé.

Pour tester le collecteur brut, utilisez les paramètres explicites :

powershell.exe -ExecutionPolicy Bypass -File .\wadyu-app-metering.ps1 `
  -CollectorUrl "https://app.wadyu.tech/api/collect/app-usage" `
  -CollectorKey "<collector-key>"

Sans ConfigJson ou ConfigPath, le collecteur brut n’a pas de cibles métier par défaut. Pour tester la vraie configuration client, utilisez plutôt le script généré par Wadyu.

La sortie attendue contient collectorPost.status = accepted, des compteurs accepted, discoveryAccepted, skipped et un requestId. Si le statut vaut not_sent, l’URL, la clé ou les observations manquent. Si le statut vaut failed, contrôlez le message : proxy, HTTPS, clé invalide, blocage géographique ou réponse serveur.

Après le test, vérifiez dans Wadyu Script Builder > Collecteur la dernière utilisation, le compteur d’observations et les derniers événements d’ingestion, puis contrôlez App Metering pour retrouver l’application, le poste et l’utilisateur.

Conformité

Documentez le périmètre de mesure auprès du client : applications ciblées, finalité, durée de conservation, personnes ayant accès aux rapports et processus de suppression. Les valeurs de rétention proposées par Wadyu suivent les principes nLPD et RGPD, mais le MSP doit les adapter au contrat client.