Intune, SCCM et le socle poste de travail : ce que la documentation officielle ne dit pas

Le "socle poste de travail" n'est pas juste une image Windows. C'est l'ensemble cohérent qui définit un poste conforme dans une organisation : sécurité, conformité, applications, mises à jour, et les règles qui les relient. Le confondre avec une simple image de déploiement est la première erreur, et elle en entraîne d'autres.

Le co-management n'est pas un compromis neutre

Faire cohabiter SCCM et Intune sur un même parc, ce n'est pas juste "les deux tournent en même temps". Chaque fonction (conformité, mise à jour Windows, déploiement d'applications, protection des endpoints...) doit être explicitement attribuée à l'une ou l'autre plateforme. Ne pas le faire, ou le faire à moitié, ouvre la porte au piège le plus fréquent : un poste qui reçoit des instructions contradictoires des deux côtés, sans qu'aucune erreur ne remonte clairement.

Le double management silencieux

C'est le scénario le plus trompeur : un poste peut apparaître conforme dans Intune et bloqué côté SCCM, ou l'inverse, sans qu'aucune des deux consoles ne signale de conflit explicite. Chacune raisonne dans son propre référentiel. Le diagnostic ne vient pas d'une alerte, il vient de l'écart entre ce que dit la console et ce que vit réellement l'utilisateur.

Autopilot contre l'historique SCCM

Un poste qui a déjà un client SCCM installé n'est pas un poste vierge pour Autopilot, même si l'image semble propre. Les frictions à l'enrôlement viennent rarement d'Autopilot lui-même — elles viennent de ce que l'ancien socle a laissé derrière lui.

Le vrai travail n'est pas technique, il est organisationnel

La bascule Intune/SCCM échoue rarement sur la configuration. Elle échoue quand personne n'a tranché, en amont, qui a l'autorité finale sur le socle poste de travail. Une fois cette gouvernance claire, la technique redevient ce qu'elle devrait être : de l'exécution, pas de l'arbitrage.