SUP-02 — Déploiement, administration et dépannage des applications d'entreprise avec SCCM/Intune

Résumé destiné aux recruteurs

Au Ministère de la Cybersécurité et du Numérique du Québec (MCN), j’interviens sur le cycle de vie des applications Windows : déploiement, mise à niveau, désinstallation, ciblage des appareils, diagnostic des installations en échec et application de correctifs. SUP-02 présente cette pratique à travers les mécanismes SCCM/MECM et Microsoft Intune : préparation de package, commande silencieuse, règle de détection, affectation, distribution, installation, vérification et traitement documenté des anomalies.

Contexte et objectifs

Un déploiement ne se résume pas à lancer un installeur. Une application doit être conditionnée pour une installation silencieuse, identifiable après installation, ciblée au bon périmètre et observable lorsqu’elle échoue. Sur Windows 10/11, les incidents peuvent provenir du client, de la réception de la politique, de la disponibilité du contenu, du contexte d’exécution, d’une dépendance, du code de retour ou d’une règle de détection inadaptée.

Les objectifs opérationnels sont les suivants :

• Déployer, mettre à niveau ou retirer une application de manière contrôlée.
• Gérer les collections SCCM/MECM et les affectations Intune/Entra ID selon le public cible.
• Distinguer une application Available demandée par l’utilisateur d’une application Required imposée au périmètre affecté.
• Analyser les journaux client et les codes de retour pour remonter à la cause du défaut plutôt que de réinstaller sans diagnostic.
• Appliquer un correctif et vérifier une nouvelle évaluation avant de clôturer l’incident.
• Documenter la méthode, le périmètre et le résultat sans divulguer de données d’organisation.

Environnement technique

Responsabilités exercées

• Déploiement d’applications.
• Mise à niveau et désinstallation.
• Gestion des collections et des déploiements ciblés.
• Diagnostic des erreurs d’installation.
• Analyse des journaux clients SCCM.
• Analyse des codes de retour.
• Application de correctifs.

Architecture 1 — SCCM/MECM

Applications, packages, collections et déploiements SCCM

Une application SCCM décrit l’intention : type de déploiement, commandes, détection, exigences, dépendances et expérience utilisateur. Un package/program est une méthode plus directe de distribution et d’exécution, sans le même modèle de détection applicative. Le choix dépend des standards de l’organisation et des caractéristiques de l’installeur ; cette fiche ne présume pas du modèle retenu pour une application MCN donnée.

Les collections d’appareils permettent un ciblage progressif par critères approuvés. Un déploiement Available est proposé dans Software Center : l’utilisateur autorisé le déclenche. Un déploiement Required est évalué et installé suivant son échéance. Avant une extension de périmètre, le package, la commande, la détection et le ciblage doivent être validés dans un périmètre pilote autorisé.

Architecture 2 — Microsoft Intune

Applications Win32 Intune, groupes et rapports

Pour une application Win32, Intune distribue un contenu empaqueté, une commande d’installation et de désinstallation, des règles de détection et, selon le besoin, des exigences ou dépendances. L’affectation repose sur des groupes Entra ID d’utilisateurs ou d’appareils. Les rapports d’installation permettent de suivre un état déclaré, mais un incident doit être recoupé avec l’appareil, l’affectation, la synchronisation et les journaux de l’agent Intune Management Extension lorsque la situation le requiert.

Architecture 3 — Workflow de déploiement

Processus de déploiement

1. Préparer l’application : identifier la version, les sources autorisées, les prérequis et le comportement attendu.
2. Créer le package adapté à la plateforme : MSI, MSIX ou contenu Win32 empaqueté.
3. Définir les commandes silencieuses d’installation et de désinstallation, avec le contexte approprié.
4. Configurer la détection : code produit, fichier, valeur de registre ou version, selon une preuve fiable d’installation.
5. Affecter à une collection SCCM/MECM ou à un groupe Entra ID, en commençant par le périmètre pilote validé.
6. Distribuer le contenu : vers le Distribution Point SCCM/MECM ou via le service Intune, selon la plateforme.
7. Installer : à la demande (Available) ou suivant une obligation/échéance (Required).
8. Vérifier la détection, l’état de déploiement et le comportement attendu sur le poste.
9. Traiter l’erreur, documenter le correctif et déclencher une nouvelle évaluation contrôlée.

Architecture 4 — Diagnostic d’un échec

Journaux SCCM et lecture du défaut

La lecture est chronologique : confirmer d’abord que le client reçoit le déploiement ciblé, puis qu’il accède au contenu, qu’il lance la commande prévue et enfin que la règle de détection constate le résultat attendu. Un code de retour ne s’interprète pas isolément : les valeurs MSI courantes comme 0 (succès), 3010 (succès avec redémarrage requis) ou 1603 (erreur générique) doivent être rapprochées de la documentation de l’éditeur, des journaux et du contexte d’exécution.

Méthodes de remédiation

Les actions concrètes sont conduites dans le cadre des procédures et autorisations en vigueur. Aucun changement de production, redéploiement massif ou suppression de contenu n’est décrit ici comme automatique.

Fiche comparative — SCCM/MECM et Intune

Démonstration documentaire — application fictive

L’exemple ci-dessous est une fiche de conception fictive pour Contoso Reader 5.4, une application imaginaire. Il sert à illustrer les éléments à documenter et ne correspond à aucun package ni déploiement du MCN.

Nom fictif       : Contoso Reader 5.4
Installation     : ContosoReader-5.4-x64.msi /qn /norestart
Désinstallation  : msiexec.exe /x {00000000-0000-0000-0000-000000000000} /qn /norestart
Détection        : code produit MSI fictif ou valeur de registre
Contexte         : système, 64 bits
Ciblage pilote   : groupe / collection de démonstration fictif

Exemple de journal fictif — AppEnforce.log
Prepared command line: msiexec.exe /i "ContosoReader-5.4-x64.msi" /qn /norestart
Process completed with exit code 3010
Detection evaluation: application detected; restart required

Procédure de diagnostic de l’exemple : confirmer le ciblage, vérifier l’arrivée de la politique, confirmer le contenu, lire AppEnforce.log, interpréter 3010 comme une installation réussie nécessitant un redémarrage, valider la détection, puis consigner l’état. Les identifiants et lignes de journal sont fictifs.

Compétences démontrées

Résultats vérifiables

• Les responsabilités documentées couvrent le déploiement, la mise à niveau, la désinstallation, le ciblage, le diagnostic, l’analyse de journaux et l’application de correctifs.
• Quatre schémas publiés décrivent les flux SCCM/MECM, Intune, le workflow et le diagnostic sans représenter d’architecture interne du MCN.
• La fiche distingue clairement les mécanismes SCCM/MECM et Intune, ainsi que les cas Available et Required.
• Aucun volume d’appareils, taux de réussite, nom de serveur, groupe, tenant ou métrique n’est inventé. Ces indicateurs restent à documenter si leur publication est autorisée.