IT Device Audit est un système d'audit de flotte éprouvé, packagé comme un modèle de projet OpenTechnologyApp. Il est né sous la forme d'une Google Sheet + Apps Script réconciliant une véritable flotte d'environ 145 appareils du secteur de la santé — JumpCloud face à SentinelOne, la gestion des navigateurs et l'inventaire des actifs — et se présente maintenant sous forme de trois files, d'automatisations fonctionnelles, et de playbooks de remédiation étape par étape que vous pouvez importer en un clic.
Le répertoire du modèle passera en open source sur GitHub — surveillez l'organisation pour le dépôt.
Ce qu'il détecte
Chaque contrôle que le système d'origine exécutait chaque semaine (ou en continu) devient un élément suivi avec un statut d'exécution et un nombre d'éléments signalés :
- T1 — Bloqueurs de sécurité : appareils sans agent EDR, fantômes EDR absents du MDM, alertes de santé critiques issues de la télémétrie côté appareil, violations de la politique de compte Microsoft
- T2 — Hygiène opérationnelle : appareils inactifs (bande d'avertissement à 14 jours, bande d'action à 30 jours), OS obsolète, uptime élevé, dérive de nom d'hôte, dérive d'unité organisationnelle du navigateur, retard des mises à jour Windows + de l'agent de mise à jour Lenovo
- T3 — Exhaustivité de l'inventaire : appareils orphelins, utilisateurs multi-appareils, dérive de version d'agent, ajout/retrait dans l'inventaire des actifs, utilisateurs non activés
Trois files, un seul système
| File | Ce qui s'y trouve |
|---|---|
| Inventaire des appareils | Un élément par appareil — numéro de série, plateforme, versions d'agent, statut de santé, jours de silence, cases à cocher de mise hors service |
| Contrôles d'audit | Un élément par métrique de contrôle, groupé par niveau, avec cadence + statut d'exécution + nombre d'éléments signalés |
| Commandes de remédiation | Les commandes MDM (installation/reconnexion EDR, renommage de nom d'hôte, application de la conformité) sous forme d'éléments déclenchables et suivis |
Des automatisations qui font un vrai travail
Pas de commentaires consultatifs pour la forme. Quand le statut EDR d'un appareil passe à Manquant, il devient urgent et atterrit dans le niveau P1. Quand un contrôle passe, il se referme tout seul. Quand un appareil retourné est marqué comme effacé, l'élément de mise hors service se ferme. Des automatisations webhook optionnelles déclenchent directement des commandes de remédiation MDM ou envoient un message direct à votre canal Slack au sujet d'un appareil inactif — livrées désactivées jusqu'à ce que vous ayez validé un cycle complet (la discipline du dry-run sur laquelle fonctionnait le système d'origine).
Playbooks : le workflow de triage, encodé
Onze runbooks s'attachent automatiquement aux types d'éléments correspondants :
- Lacune EDR — installation contre reconnexion, par plateforme, avec une étape de vérification
- Appareil inactif — confirmer que l'utilisateur est actif, reconnecter ou orienter vers la mise hors service
- Mise hors service — le démantèlement en quatre systèmes (MDM, EDR, inventaire des actifs, enregistrement du navigateur), chaque étape cochant une case
- Conformité de compte Microsoft / Versions d'agent / Communications utilisateur / Appareils orphelins — les priorités de triage hebdomadaire P1–P7 sous forme d'étapes guidées, modèles Slack inclus
- Runbook de redéploiement de webhook et une checklist de changement de fournisseur — les leçons opérationnelles durement acquises, pour que le prochain administrateur n'ait pas à les réapprendre
Connecté à votre flotte, pas seulement descriptif
Deux scripts inclus relient le modèle à une infrastructure réelle :
jumpcloud-sync.js— script cron qui récupère les appareils depuis l'API JumpCloud et met à jour les éléments d'inventaire avec le calcul des jours de silence et le routage du statutdevice-post-ingest.js— un webhook entrant qui accepte les POST de télémétrie côté appareil (santé Windows, santé Mac, réseau, conformité MS — les quatre contrats de payload), évalue les alertes critiques, et met à jour les appareils en place
La couche MDM est délibérément interchangeable : le script de synchronisation est le seul élément spécifique à JumpCloud. Pointez-le vers Kandji, Intune, ou Mosyle en mappant leur API vers la même forme d'appareil normalisée — les contrôles, tableaux de bord et playbooks ne changent pas.
Comment l'obtenir
Importez IT Device Audit depuis le sélecteur de modèles dans OpenTechnologyApp — c'est intégré. Les fichiers de modèle autonomes (JSON + scripts + runbooks) arrivent bientôt sur l'organisation GitHub OpenTechnology14 sous forme de répertoire open source.