L’essentiel à retenir avant d’ouvrir la console
- La console Intune sert à inscrire, configurer, sécuriser et mettre à jour des appareils, puis à déployer et protéger des applications.
- On y accède depuis un navigateur compatible, avec une licence et des droits RBAC adaptés.
- Les usages les plus fréquents concernent Windows, Apple, Android et Linux.
- Company Portal répond à un autre besoin: l’accès aux apps et aux appareils côté employé ou étudiant.
- Pour un déploiement propre, il faut cadrer les rôles, les groupes cibles et la stratégie d’inscription avant d’aller plus loin.
Ce que fait réellement la console d’administration Intune
Intune n’est pas seulement un menu de plus dans Microsoft 365. C’est une plateforme cloud de gestion des terminaux qui couvre le cycle de vie des appareils et des applications: inscription, configuration, protection, mises à jour, conformité et contrôle d’accès. Quand j’explique Intune à une équipe IT, je le résume ainsi: la console sert à décider qui peut utiliser quel appareil, avec quelles applications et dans quel niveau de confiance.
On parle souvent de MDM et de MAM. MDM signifie mobile device management, donc la gestion des appareils; MAM signifie mobile application management, donc la gestion des applications et de leurs règles d’usage. Dans Intune, ces deux couches se complètent: on peut gérer un poste entier, ou seulement encadrer les données d’une application d’entreprise.
Dans la pratique, je vois surtout quatre blocs de travail revenir en boucle:
| Zone | Ce que je fais | Pourquoi c’est utile |
|---|---|---|
| Appareils | Inscription, configuration, conformité, actions à distance | Garantir qu’un terminal reste conforme aux règles de l’entreprise |
| Applications | Déploiement, affectation, protection, mise à jour | Donner les bons outils sans surcharger les utilisateurs |
| Sécurité | Politiques de sécurité, protections de base, intégrations Defender | Réduire la surface de risque sans multiplier les exceptions |
| Rapports | État des postes, santé, conformité, tendances | Voir ce qui fonctionne réellement, pas seulement ce qui a été configuré |
Comment y accéder sans se tromper de portail
Le centre d’administration Intune s’ouvre dans un navigateur via l’adresse du service et, dans certains cas, depuis le centre d’administration Microsoft 365 ou le portail Azure. Pour la console elle-même, je conseille de partir du navigateur le plus simple de l’équipe, mais de rester sur les versions prises en charge: Microsoft Edge, Safari sur Mac, Chrome et Firefox. Quatre navigateurs, pas plus, et c’est souvent là que les premiers incidents se cachent.
Voici les conditions que je vérifie systématiquement avant d’annoncer qu’un environnement est prêt:
| Élément | Ce qu’il faut | Pourquoi c’est important |
|---|---|---|
| Navigateur | Une version prise en charge | Éviter les bugs d’interface et les comportements incohérents |
| Compte | Un compte professionnel ou scolaire | L’accès se fait par authentification d’entreprise, pas en simple visiteur |
| Droits | Des permissions RBAC Intune adaptées | La console affiche seulement ce que le rôle autorise réellement |
| Licence | Une licence Intune assignée quand elle est nécessaire | Un droit d’administration sans capacité licenciée bloque vite les usages |
Je vois souvent une erreur de lecture: certains pensent que le simple fait d’avoir un compte Microsoft suffit. En réalité, l’accès à la console dépend des rôles et de la portée de gestion, avec un compte Intune Administrator possible pour démarrer, puis une logique de moindre privilège à appliquer ensuite. Une fois connecté, la vraie question devient donc ce que l’on pilote au quotidien.
Ce que l’on pilote au quotidien dans Intune
Le cœur de la console est très opérationnel. J’y vois quatre usages qui reviennent tout le temps: inscrire les appareils, déployer les applications, appliquer les politiques de sécurité et lire les rapports. Sur un projet bien tenu, ces blocs restent clairs; sur un projet mal gouverné, ils se mélangent et deviennent difficiles à exploiter.
Je résume souvent les usages clés de cette manière:
| Usage | Exemple concret | Effet attendu |
|---|---|---|
| Inscription des appareils | Rattacher un poste Windows, un iPhone ou une tablette Android au tenant | L’appareil reçoit ensuite les règles et les profils de l’organisation |
| Déploiement d’applications | Rendre une application disponible ou obligatoire pour un groupe | Les utilisateurs obtiennent les bons outils, au bon moment |
| Politiques de conformité | Exiger le chiffrement, le code PIN ou une version minimale du système | Réduire le risque d’accès depuis un terminal trop faible ou mal protégé |
| Sécurité des terminaux | Déployer des paramètres de protection ou des stratégies de sécurité | Normaliser le niveau de défense sans configurer poste par poste |
| Rapports et visibilité | Mesurer la conformité, les tendances et l’état des appareils | Décider sur des données réelles plutôt que sur des impressions |
Je rappelle toujours qu’une action distante n’est pas magique: un appareil doit être inscrit, joignable et autorisé pour répondre correctement. C’est pour cette raison que les rapports et le suivi de conformité ont autant de valeur que les politiques elles-mêmes. Et avant de déployer à grande échelle, il faut préparer le terrain.
Ce qu’il faut préparer avant un déploiement en production
Le plus gros malentendu avec Intune, c’est de croire que la console fera le travail de conception à votre place. En pratique, il faut décider très tôt des rôles, des groupes cibles, du mode d’inscription et du niveau de contrôle attendu pour les appareils personnels et professionnels.
Quand je structure un projet, je commence presque toujours par les mêmes points:
- Définir les rôles RBAC, c’est-à-dire qui peut lire, modifier ou approuver quoi.
- Créer un groupe pilote de 20 à 50 appareils pour valider les politiques avant l’extension.
- Séparer les usages BYOD et les appareils appartenant à l’entreprise.
- Choisir la méthode d’inscription adaptée à chaque plateforme, au lieu d’imposer une règle unique partout.
- Vérifier les licences, les restrictions d’inscription et les dépendances réseau avant le lancement.
Le point RBAC mérite d’être traité avec sérieux. RBAC signifie role-based access control: chaque admin n’obtient que les permissions nécessaires à sa mission, pas davantage. C’est moins spectaculaire qu’un déploiement massif, mais c’est ce qui évite les erreurs de manipulation les plus coûteuses. Une fois cette base en place, il devient plus simple de distinguer la console d’administration des autres portails Microsoft.
Ne pas confondre la console Intune avec Company Portal et les autres portails Microsoft
C’est probablement la confusion la plus coûteuse en temps. Intune, Company Portal, le centre d’administration Microsoft 365 et le portail Azure peuvent tous être liés au même tenant, mais ils ne servent pas le même public ni les mêmes tâches.
| Outil | Pour qui | Usage principal | Ce qu’il ne remplace pas |
|---|---|---|---|
| Console d’administration Intune | Équipes IT et sécurité | Gérer les appareils, les applications, la conformité et les politiques | Le self-service utilisateur |
| Company Portal | Employés et étudiants | Accéder aux ressources internes, installer des apps, vérifier l’état d’un appareil | Les fonctions d’administration avancée |
| Centre d’administration Microsoft 365 | Administrateurs Microsoft 365 | Gérer utilisateurs, licences et services Microsoft 365 | Le pilotage fin des politiques Intune |
| Portail Azure | Administrateurs cloud et identité | Gérer Microsoft Entra et les ressources Azure | La console Intune comme espace de travail quotidien |
Si un utilisateur final doit seulement installer des applications approuvées, Company Portal suffit. Si l’objectif est d’imposer la conformité, de remonter des rapports et de lancer des actions à distance, il faut Intune côté administration. Cette distinction paraît simple sur le papier, mais elle règle à elle seule une bonne partie des tickets de démarrage.
Les erreurs qui font perdre du temps
Les blocages que je rencontre sont rarement “mystérieux”. Ils viennent presque toujours d’un mauvais cadrage initial, d’un compte mal préparé ou d’une confusion entre les différents espaces Microsoft.
- Confondre licence et autorisation: une licence Intune ne remplace pas un rôle RBAC, et l’inverse est vrai aussi.
- Tester sur un navigateur ou un profil de session mal propre: beaucoup de faux bugs viennent des caches, des cookies ou d’une vieille session Microsoft.
- Déployer à tout le monde trop tôt: sans groupe pilote, la moindre mauvaise règle se propage vite.
- Oublier le statut de l’appareil: un terminal non inscrit, hors ligne ou non conforme n’obéit pas comme un poste déjà enrôlé et en règle.
- Utiliser le mauvais outil pour le support: le menu de dépannage du centre Intune aide à diagnostiquer, mais l’ouverture de tickets dépend des droits du compte.
J’ajoute un point que beaucoup sous-estiment: les problèmes d’accès ne sont pas toujours des problèmes Intune. Ils peuvent venir de l’authentification, de l’identité Microsoft Entra, du navigateur ou d’une politique d’accès conditionnel trop stricte. Avant d’accuser la console, je vérifie toujours la chaîne complète. C’est là que l’on gagne du temps.
Le point de départ que je recommande pour un environnement Microsoft sain
Si je devais démarrer un projet Intune en 2026, je commencerais par trois choses: un pilote réduit, des rôles minimalistes et une séparation nette entre administration et self-service. Cette discipline paraît simple, mais c’est elle qui évite les environnements impossibles à maintenir six mois plus tard.
Mon repère est assez direct: la console d’administration Intune sert aux équipes IT qui veulent gouverner les terminaux et les applications, tandis que Company Portal sert aux utilisateurs qui doivent simplement accéder à leurs outils. Quand ces deux usages restent séparés, Intune devient un vrai levier cloud plutôt qu’un portail de plus à subir.
