IT Device Audit est un workflow d'audit de flotte packagé comme un modèle de projet OpenTechnologyApp. Importez-le en un clic et vous obtenez trois files, des automatisations réelles, cinq playbooks de triage, et deux tableaux de bord — préchargés avec des données d'exemple pour que vous voyiez la forme avant de toucher un appareil réel.
Le répertoire du modèle passera en open source sur GitHub — surveillez l'organisation pour le dépôt.
Trois files, un seul système
| File | Ce qui s'y trouve |
|---|---|
| Device Inventory | Un élément par appareil — numéro de série, nom d'hôte, plateforme, utilisateur assigné, version d'OS, dernier contact, statut de santé, et la fraîcheur de la donnée sous-jacente |
| Audit Findings | Un élément par constat — santé de l'appareil, appareil inactif, conformité OS, écart d'inventaire, écart d'identité, santé réseau, ou une revue manuelle signalée — avec sévérité et statut (ouvert, en investigation, bloqué, résolu, supprimé) |
| Audit Runs | Un élément par passage d'audit quotidien, hebdomadaire ou ad hoc — cadence, périmètre, statut d'exécution, et combien d'appareils ont été vérifiés et de constats ouverts ou résolus |
Des automatisations qui font un vrai travail
Trois automatisations sont livrées activées, pas comme des commentaires consultatifs. Quand le statut de santé d'un appareil passe à Critical, l'élément passe en priorité urgente. Quand le statut d'un constat passe à Resolved, l'élément se ferme. Quand le statut d'un passage d'audit passe à Failed, il devient urgent aussi — pour qu'un passage d'audit en échec attire l'attention au lieu de passer inaperçu.
Deux flux planifiés créent le travail d'audit lui-même : l'un dépose un nouvel élément Daily Device Audit dans Audit Runs chaque jour, l'autre un élément Weekly Device Audit chaque lundi. Les deux sont des éléments de checklist à traiter par une personne — aucun n'envoie d'e-mail.
Playbooks : le workflow de triage, encodé
Cinq playbooks s'attachent automatiquement aux types d'éléments correspondants, chacun une courte liste d'étapes requises plutôt qu'un mur de texte :
- Daily Device Audit — confirmer la fraîcheur de la source (ou marquer le passage comme bloqué), revoir les appareils Critical/Warning/Unknown, créer ou mettre à jour des constats, enregistrer les compteurs et clôturer le passage
- Weekly Device Audit — revue de la santé des appareils et des appareils inactifs, réconciliation d'inventaire et d'identité, revue de la santé réseau, constats vieillissants/bloqués, puis enregistrer le résultat
- Critical Device Health — valider les preuves, assigner un responsable et une étape de confinement immédiate, enregistrer la résolution ou l'escalade
- Stale Device Review — confirmer le dernier contact et l'utilisateur assigné, décider actif/hors ligne/retourné/retiré, mettre à jour le constat
- Inventory and Identity Review — vérifier numéro de série, nom d'hôte et utilisateur assigné, identifier l'enregistrement faisant autorité, enregistrer la correction ou une exception acceptée
Deux tableaux de bord
Device Health montre le statut des appareils en un coup d'œil, la santé ventilée par plateforme, les constats ouverts par sévérité, et une liste en direct de tout appareil Critical, Warning ou Unknown. Audit Operations montre le statut du travail d'audit, les passages par cadence, les constats par type, et les suivis d'audit ouverts.
Ce qui est livré versus ce que vous connectez vous-même
Le modèle lui-même n'a aucun connecteur de gestionnaire d'appareils intégré — ce sont des files, des champs, des automatisations, des playbooks et des tableaux de bord, chargés avec des appareils et constats d'exemple clairement étiquetés pour que la forme soit évidente dès l'import. Le pointer vers une flotte réelle est une étape séparée et délibérée.
Deux scripts de démarrage dans le répertoire du modèle sont un point de départ pour cette étape, pas une intégration prête à l'emploi : jumpcloud-sync.js récupère les appareils depuis l'API JumpCloud selon un planning, et device-post-ingest.js est un point de terminaison webhook pour la télémétrie de santé, réseau et conformité côté appareil. Les deux sont pensés pour être lus et adaptés — mappez leur sortie vers les champs de la file que vous voulez réellement remplir — pas collés tels quels comme un produit fini. La couche MDM est délibérément interchangeable : rien dans les files, playbooks ou tableaux de bord n'est spécifique à JumpCloud.
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 (champs + scripts) arrivent bientôt sur l'organisation GitHub OpenTechnology14 sous forme de répertoire open source.