Jamf School : diagnostiquer les commandes MDM terminées
Comment enquêter sur un profil qui semble installé sans produire le résultat attendu ? L’évolution Jamf School du 2 novembre 2026 donne un point d’appui supplémentaire. Voici la méthode de diagnostic proposée par Underside pour relier commande, résultat sur l’appareil et décision de support, sans confondre un historique technique avec une preuve de conformité.
1. Le périmètre confirmé par Jamf
Les notes officielles annoncent Management History (Beta), à disponibilité limitée. Dans les détails d’un appareil, cette catégorie présente les commandes terminées des 90 derniers jours : type, détails, dates de mise en file et de fin, statut. Les filtres portent sur le type, le statut et la date de fin. Vérifiez d’abord que votre environnement y a accès ; cette annonce ne concerne pas Jamf Pro.
2. Commencer par une question vérifiable
Notre recommandation : ouvrez un ticket avec un seul résultat attendu, par exemple « le profil de configuration pilote doit être présent sur cet iPad ». Notez l’identifiant de l’appareil dans votre outil interne, le profil attendu, la plage horaire et le fuseau utilisés. Évitez une nouvelle distribution à grande échelle avant d’avoir compris le premier résultat.
Si la bêta est disponible, recherchez la commande concernée et relevez son statut et ses horodatages. Si aucune entrée ne correspond, ne concluez pas automatiquement à un échec : votre recherche porte sur des commandes terminées et sur une fenêtre limitée. Examinez le périmètre de distribution et poursuivez le diagnostic dans les outils disponibles.
3. Séparer exécution technique et service rendu
Nous proposons de documenter deux vérifications distinctes. D’abord, que dit le suivi de la commande ? Ensuite, l’appareil présente-t-il effectivement la configuration et le comportement attendus ? Pour un profil Wi-Fi pilote, testez une connexion autorisée sur le réseau prévu et relevez le résultat. Un statut de commande ne suffit pas, à lui seul, à valider l’accès métier.
- Résultat attendu : consigner la configuration vérifiée et le test d’usage.
- Échec : conserver le statut observé et le contexte avant toute nouvelle tentative ciblée.
- Résultat ambigu : comparer avec un appareil témoin et demander une analyse support plutôt que multiplier les actions.
4. Une fiche utile aux organisations belges et françaises
Pour une équipe IT multisite en Belgique ou en France, nous conseillons un format commun : ticket, appareil, commande, profil, horodatages avec fuseau, statut, observation locale, responsable et prochaine action. Cette fiche facilite la reprise entre équipes francophones et anglophones, établissements et prestataires. Limitez les données partagées à ce qui est nécessaire à l’incident, selon vos règles internes.
Les entreprises utilisant un autre MDM peuvent reprendre cette méthode de rapprochement, mais doivent vérifier les fonctions de leur propre console. La nouveauté documentée ici reste propre à Jamf School ; elle ne constitue pas une extension d’Apple Business Manager ou de Jamf Pro.
5. Analyse Underside : intégrer la preuve au support
Notre lecture est opérationnelle : utilisez cet historique comme une pièce du dossier de diagnostic. Nous recommandons de définir qui vérifie le résultat sur l’appareil et qui autorise une nouvelle tentative. Pour une PME, une fiche courte peut suffire ; pour une grande organisation ou une administration, rattachez-la au processus de changement et à l’escalade support.
Ce guide complète notre analyse des changements d’accès à Jamf School. Pour structurer votre gestion de flotte, consultez aussi nos pages Apple entreprise en Belgique et Apple entreprise en France.
Sources officielles : Jamf School Release Notes — 2026-11-02 · Device Management History (Beta).