Projet de portfolio Microsoft Intune au Maroc : un exercice pratique de A à Z

Choisir un projet adapté à son niveau

Un bon projet concret Microsoft Intune est limité, compréhensible et lié à une situation professionnelle. Il doit montrer une suite de décisions — pas uniquement le résultat final. Un recruteur ou un client doit pouvoir comprendre le besoin, les choix de configuration et les vérifications effectuées, même s’il n’a pas accès à votre environnement.

Pour débuter, évitez de vouloir représenter toute la gestion informatique d’une grande entreprise. Limitez le périmètre à une petite flotte fictive, à un seul type de système d’exploitation et à quelques règles de gestion clairement expliquées. Vous pourrez ensuite présenter une extension possible, sans prétendre l’avoir déployée.

Choisissez un périmètre que vous pouvez réellement tester avec les droits, licences et équipements à votre disposition. Les fonctions disponibles et les étapes exactes peuvent dépendre de la configuration de l’environnement Microsoft utilisé. Dans votre portfolio, indiquez ce que vous avez pu tester et ce qui reste une proposition.

• Un problème précis, formulé en une ou deux phrases.
• Un environnement de démonstration autorisé, avec des utilisateurs et appareils de test.
• Des livrables consultables sans connexion à votre tenant.
• Des critères de réussite observables, tels que l’application d’une stratégie ou l’affichage d’un état attendu.
• Un périmètre assez modeste pour être documenté et vérifié de bout en bout.

Partir d’un besoin concret

Pour l’exercice, imaginez une petite entreprise marocaine fictive qui fournit des ordinateurs portables à ses collaborateurs. Elle veut disposer d’une méthode cohérente pour inscrire des appareils de test, appliquer quelques règles de configuration et vérifier leur état depuis un point central. Le besoin n’est pas de garantir une sécurité complète, mais de montrer comment un administrateur aborde un premier pilote.

Avant de toucher à Intune, rédigez un brief d’une page. Donnez un nom fictif à l’organisation, décrivez les utilisateurs concernés, le type d’appareils dans le périmètre et les résultats attendus. Distinguez les exigences — par exemple, disposer d’un inventaire et appliquer une configuration définie — des idées envisagées pour une phase ultérieure.

Évitez de présenter une règle comme universellement adaptée à toutes les entreprises. Les paramètres appropriés dépendent des usages, des appareils, des exigences internes et du contexte de sécurité. Votre portfolio doit montrer que vous savez poser ces questions, et non que vous avez trouvé une configuration magique.

• Objectif : démontrer un pilote de gestion centralisée sur un petit nombre d’appareils de test.
• Utilisateurs : profils fictifs, par exemple « collaborateur » et « administrateur de test ».
• Résultat attendu : expliquer l’inscription, la configuration retenue et la manière de vérifier l’état des appareils.
• Hors périmètre : appareils personnels réels, données de clients, déploiement en production et promesse de conformité réglementaire.

Préparer les données, fichiers ou ressources

Un portfolio convaincant est préparé avant la configuration. Faites l’inventaire des ressources nécessaires et vérifiez que vous êtes autorisé à les utiliser. Si vous n’avez pas accès à un environnement de test adéquat, documentez la conception et les contrôles prévus sans affirmer que vous avez exécuté des tests.

Utilisez des noms de tenant, de groupes, d’utilisateurs et d’appareils entièrement fictifs dans les documents que vous partagez. Les captures d’écran peuvent révéler des noms d’organisation, des identifiants, des adresses, des numéros de série, des informations sur les appareils ou des paramètres internes. Masquez ces éléments avant toute publication et contrôlez aussi les détails visibles dans les onglets et notifications.

Ne publiez jamais de mots de passe, clés, jetons, codes de récupération, informations d’accès, fichiers appartenant à un employeur ou données personnelles. N’importez pas de listes réelles d’utilisateurs ou d’appareils. Si un élément confidentiel apparaît par erreur dans un fichier ou une capture, retirez-le avant la diffusion plutôt que de compter sur le fait qu’il sera peu visible.

• Un compte ou tenant de démonstration et les droits nécessaires, si vous en disposez.
• Un ou plusieurs appareils de test compatibles avec votre scénario, ou une conception documentée si le test matériel n’est pas possible.
• Un tableau d’inventaire fictif : identifiant inventé, type d’appareil et rôle de test.
• Un dossier de projet avec brief, schéma, journal des changements, tests et captures expurgées.
• Une liste des données sensibles à repérer et à supprimer avant le partage.

Réaliser le projet par étapes

Travaillez par petites étapes et consignez ce que vous faites. Pour chaque modification, notez son objectif, le périmètre concerné et le résultat attendu. Si une fonction ou un réglage n’est pas disponible dans votre environnement, signalez-le comme une limite au lieu de le remplacer par une capture inventée.

L’exercice ci-dessous est conçu pour un projet débutant. Il présente une démarche de travail, pas une configuration universelle ni une procédure de mise en production.

• 1. Définir le périmètre. Confirmez le scénario, les appareils concernés, les critères de réussite et les éléments explicitement exclus. Écrivez aussi les hypothèses, notamment le type d’appareil et le mode de test.
• 2. Dessiner la solution. Réalisez un schéma simple montrant les utilisateurs et appareils fictifs, leur inscription prévue, les stratégies envisagées et l’endroit où l’administrateur consultera les résultats. Étiquetez clairement les éléments réalisés et ceux
• 3. Préparer la structure. Dans l’environnement de test, créez les groupes et objets nécessaires au périmètre, avec des noms explicites et fictifs. Avant d’affecter une stratégie, vérifiez à quels utilisateurs et appareils elle s’appliquera.
• 4. Configurer un petit ensemble de règles. Choisissez quelques réglages adaptés à l’objectif de démonstration, expliquez leur rôle et consignez les valeurs utilisées. Ne recopiez pas une politique d’entreprise réelle. Si votre scénario exige des fonctions non
• 5. Inscrire ou préparer l’appareil de test. Suivez le parcours autorisé pour votre environnement, puis vérifiez que l’appareil apparaît dans l’espace d’administration attendu. Si vous ne pouvez pas réaliser l’inscription, documentez l’étape prévue et laissez
• 6. Vérifier l’application des paramètres. Contrôlez les états disponibles dans l’environnement et comparez-les aux résultats attendus. Notez les délais, erreurs ou différences observées sans prétendre qu’un état « conforme » démontre à lui seul la sécurité
• 7. Faire une revue finale. Relisez les affectations, le périmètre, les captures et les documents. Faites vérifier le contenu par une autre personne si possible, surtout avant une publication publique.

Tester, corriger et documenter

La qualité du projet se voit dans la façon dont vous vérifiez le résultat et rendez les écarts compréhensibles. Un test doit indiquer ce qui a été contrôlé, dans quelles conditions et ce qui a été observé. Si un résultat n’a pas pu être confirmé, indiquez-le. Cette précision est plus utile qu’une affirmation générale de réussite.

Conservez un journal de tests lisible : identifiant du test, prérequis, action, résultat attendu, résultat constaté et décision. Si vous corrigez un paramètre, expliquez pourquoi et refaites les contrôles concernés. N’incluez pas dans votre portfolio des identifiants ou détails issus d’un vrai environnement.

• Le périmètre de chaque stratégie correspond-il aux utilisateurs ou appareils de test prévus ?
• Les noms, groupes et appareils présentés dans les documents sont-ils fictifs ?
• L’inscription a-t-elle été réellement testée, ou seulement décrite comme une étape prévue ?
• Les paramètres configurés correspondent-ils au brief et sont-ils expliqués ?
• Les états observés correspondent-ils aux résultats attendus, ou les écarts sont-ils documentés ?
• Les captures sont-elles lisibles, datées si nécessaire et expurgées des données confidentielles ?
• Le guide permet-il à une autre personne de comprendre le scénario, les changements et les limites ?
• Avez-vous retiré les secrets, informations d’accès, données personnelles et éléments appartenant à un tiers ?

Présenter son travail dans un portfolio

Présentez le projet comme une étude de cas courte : contexte fictif, objectif, périmètre, démarche, résultats observés et prochaines étapes. Commencez par expliquer le besoin, puis montrez comment vous l’avez traité. Évitez de laisser le lecteur interpréter seul une capture d’écran ou une liste de paramètres.

Les livrables utiles sont un brief, un schéma de flux ou d’architecture, une description des stratégies retenues, un journal de tests et un guide succinct pour reproduire la démonstration. Ajoutez quelques captures expurgées uniquement lorsqu’elles apportent une preuve visuelle. Une courte vidéo peut compléter le dossier si elle ne révèle ni données réelles ni accès confidentiels.

Distinguez clairement les tâches réalisées, les vérifications effectivement menées et les recommandations non testées. Précisez les limites : par exemple, le petit périmètre, l’absence de déploiement en production ou les fonctions que votre environnement ne permettait pas d’examiner. Cette transparence aide un recruteur ou un client à évaluer votre contribution réelle.

Pour un CV ou un entretien, résumez le projet en quelques lignes : besoin traité, éléments configurés, méthode de test et livrables. Préparez-vous à justifier vos choix et à expliquer ce que vous modifieriez pour une entreprise réelle après avoir recueilli ses exigences.

• Une page de synthèse : contexte fictif, objectif, périmètre et résultat.
• Un schéma lisible de la démarche et des composants concernés.
• Un tableau de tests avec les résultats constatés et les écarts.
• Des captures nettoyées, sans identifiants ni données sensibles.
• Une section « limites et suites possibles » qui sépare les faits des propositions.

Le parcours, étape par étape

1. 1Cadrer le besoin — Choisissez un scénario fictif, rédigez le brief et fixez des critères de réussite vérifiables. Délimitez ce qui est exclu.
2. 2Préparer un environnement sûr — Réunissez les droits, appareils et ressources de test disponibles. Utilisez des identités fictives et n’intégrez aucune donnée d’entreprise ou de client.
3. 3Concevoir avant de configurer — Dessinez le parcours prévu, définissez les groupes et justifiez chaque stratégie au regard du besoin.
4. 4Réaliser et consigner — Configurez uniquement le périmètre autorisé, notez les changements et indiquez ce qui a été testé ou seulement décrit.
5. 5Contrôler et corriger — Exécutez la checklist, documentez les résultats et les écarts, puis reprenez les tests concernés après toute correction.
6. 6Publier une étude de cas honnête — Expurgez les informations sensibles, présentez les livrables et précisez les limites du projet et les pistes d’amélioration.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. FormaGroup — Microsoft Intune formagroup.ma
2. Formation intra-entreprise — OFPPT ofppt.ma
3. Microsoft Learn learn.microsoft.com
4. JobInTech jobintech.academy