Portfolio SharePoint Server au Maroc : réalisez un projet concret de bout en bout

Choisir un projet adapté à son niveau

Un projet SharePoint Server débutant doit être assez réduit pour être terminé, mais assez concret pour révéler votre façon de travailler. Plutôt qu’un portail complet couvrant toute une organisation, réalisez un espace documentaire destiné à une petite équipe fictive. Vous pourrez y ranger des procédures, les classer, proposer des vues utiles et expliquer qui peut consulter ou modifier les contenus.

Avant de commencer, vérifiez que vous disposez d’un environnement SharePoint Server autorisé, d’un compte doté des droits nécessaires et d’un moyen de tester le site sans perturber un système utilisé par une entreprise. SharePoint Server est déployé sur site ; les versions, configurations et droits disponibles peuvent donc différer d’un environnement à l’autre. Notez la version et les limites de votre environnement au lieu de supposer qu’une fonction existe partout.

Définissez un périmètre qui tient en quelques résultats observables. Par exemple : un site d’équipe, une bibliothèque de documents, des colonnes de classement, deux ou trois vues et une page d’accueil qui oriente l’utilisateur. Évitez d’ajouter du développement personnalisé, des flux complexes ou une intégration avec d’autres systèmes avant d’avoir validé ce socle.

Pour choisir entre plusieurs idées, posez-vous quatre questions : le problème est-il facile à expliquer ? Les utilisateurs et leurs besoins sont-ils identifiables ? Pouvez-vous créer des données fictives représentatives ? Pouvez-vous démontrer le résultat avec les droits réellement disponibles ? Si une réponse est non, simplifiez le scénario.

• Débutant : créer le site, organiser une bibliothèque et présenter des documents avec des métadonnées et des vues.
• Niveau intermédiaire : ajouter une organisation plus fine des contenus, documenter des rôles d’accès et tester des parcours utilisateur distincts.
• Plus avancé : proposer, si l’environnement le permet, une validation de contenu ou une personnalisation supplémentaire, en précisant ses dépendances.

Partir d’un besoin concret

Un portfolio gagne en crédibilité lorsqu’il commence par un besoin métier plutôt que par une liste d’outils. Imaginez une petite entreprise fictive où les employés ne savent pas quelle procédure utiliser, trouvent plusieurs copies du même document ou ne parviennent pas à distinguer une version à jour d’une ancienne. Votre projet consiste à concevoir un espace de référence où les documents sont classés, repérables et présentés de façon cohérente.

Gardez le scénario assez précis pour guider vos décisions. Par exemple, l’espace est destiné à une équipe administrative qui consulte des procédures internes fictives. Les collaborateurs doivent pouvoir retrouver les documents par catégorie et par service ; un responsable de contenu doit pouvoir mettre à jour les fichiers. Le projet ne prétend pas remplacer un système de gestion documentaire complet : il démontre une première organisation adaptée à un besoin limité.

Rédigez un brief avant de configurer SharePoint. Celui-ci sert de fil conducteur pendant la réalisation et permet à une personne qui découvre le portfolio de comprendre ce que vous avez livré.

• Objectif : concevoir un intranet documentaire de démonstration pour aider une équipe fictive à retrouver les procédures en vigueur.
• Utilisateurs : un lecteur qui consulte les documents et un gestionnaire qui les ajoute ou les met à jour.
• Périmètre : un site, une bibliothèque documentaire, des colonnes de classement, des vues adaptées aux usages et une page d’accueil explicative.
• Critères de réussite : un utilisateur peut repérer un document à partir d’un classement annoncé ; le gestionnaire peut ajouter un fichier et renseigner ses propriétés ; les droits sont vérifiés dans la mesure permise par l’environnement.
• Livrables : brief, schéma de navigation, inventaire des champs, captures expurgées, scénario de démonstration, checklist de tests et courte note sur les limites.

Préparer les données, fichiers ou ressources

Un bon exercice pratique SharePoint Server commence par des ressources simples et sûres. Créez quelques documents fictifs : par exemple, des modèles de procédure portant des noms inventés et des contenus sans valeur opérationnelle. Vous pouvez aussi utiliser des fichiers de démonstration dont la licence autorise cet usage. Ne réutilisez pas les documents d’un employeur, d’un client ou d’un organisme de formation sans autorisation explicite.

Préparez un petit inventaire avant de créer la bibliothèque. Pour chaque document, choisissez un titre, une catégorie, un service fictif, un statut de démonstration et une date cohérente. Les valeurs doivent être assez variées pour éprouver les filtres et les vues, sans chercher à reproduire un référentiel réel. Un tableau de préparation facilite ensuite le contrôle des propriétés saisies.

Réfléchissez aux droits dès le départ. Dans une démonstration, distinguez au minimum le parcours d’une personne qui consulte de celui d’une personne qui gère les contenus. Ne donnez pas à entendre que votre configuration reproduit une politique de sécurité d’entreprise : indiquez les rôles testés et les limites de votre environnement. Ne modifiez jamais les permissions d’un système partagé sans accord de son responsable.

Gardez une trace de vos choix : nom du site, organisation des contenus, colonnes retenues, vues créées et hypothèses faites. Cette documentation rend le projet reproductible et vous évite de devoir vous fier à votre mémoire lors de la présentation.

• À réunir : accès autorisé à SharePoint Server, scénario écrit, documents fictifs, liste des catégories et matrice simple des utilisateurs et de leurs besoins.
• À exclure : données personnelles, informations commerciales, coordonnées, identifiants, captures d’écran d’un environnement client et fichiers internes non autorisés.
• À contrôler avant publication : nom des fichiers, propriétés visibles, URL internes, noms de comptes, notifications et éléments d’interface susceptibles de révéler une organisation réelle.

Réaliser le projet par étapes

Travaillez dans un ordre qui vous permet de vérifier chaque décision avant d’en ajouter une nouvelle. Le but n’est pas de reproduire toutes les possibilités de SharePoint Server, mais de montrer une réalisation cohérente avec le brief.

Commencez par confirmer les contraintes de l’environnement : version, modèle de site disponible, fonctionnalités activées et droits accordés. Notez ces éléments dans votre dossier de projet. Si une étape dépend d’une autorisation que vous n’avez pas, ne cherchez pas à la contourner : adaptez le périmètre et mentionnez la limite.

Créez ensuite le site de démonstration et donnez-lui un nom explicite, sans reprendre celui d’une entreprise réelle. Ajoutez une page d’accueil courte qui explique la finalité de l’espace, les publics visés et la façon de retrouver les contenus. Un visiteur doit comprendre en quelques instants où il se trouve et ce qu’il peut faire.

Configurez une bibliothèque documentaire puis ajoutez les colonnes nécessaires au scénario. Par exemple, une catégorie, un service fictif et un état de publication peuvent suffire. Des colonnes utiles facilitent le classement ; multiplier les champs sans usage clair rend la saisie plus lourde et fragilise la démonstration.

Ajoutez les fichiers fictifs et renseignez leurs propriétés de manière homogène. Créez ensuite des vues répondant à des questions précises : quels documents sont rattachés à une catégorie donnée ? Quels contenus sont destinés à tel service fictif ? Chaque vue doit avoir un nom intelligible et une utilité que vous pouvez expliquer.

Configurez les accès uniquement dans le cadre autorisé. Vérifiez séparément ce que peut faire un lecteur et ce que peut faire un gestionnaire, si votre environnement permet ces essais. Si vous ne pouvez pas tester un deuxième profil, indiquez-le clairement et présentez la matrice des droits comme une proposition, non comme une fonction validée.

• Étape 1 — Cadrer : relire le brief, fixer la version et l’environnement, confirmer les droits et conserver une liste de contraintes.
• Étape 2 — Concevoir : dessiner la navigation, définir la bibliothèque et choisir uniquement les propriétés nécessaires.
• Étape 3 — Construire : créer le site, la page d’accueil et la bibliothèque, puis ajouter les colonnes prévues.
• Étape 4 — Alimenter : intégrer des fichiers fictifs, renseigner les propriétés et vérifier leur cohérence.
• Étape 5 — Organiser : créer les vues, tester la navigation et contrôler les parcours lecteur et gestionnaire.
• Étape 6 — Préparer la démonstration : remettre l’espace dans un état propre, sélectionner des exemples neutres et noter les manipulations à montrer.

Tester, corriger et documenter

Ne vous contentez pas de constater que les pages s’affichent. Testez des tâches réalistes : retrouver une procédure, filtrer une liste, ouvrir un document, comprendre son statut et, pour le rôle concerné, ajouter ou modifier un fichier. Un test est plus parlant lorsqu’il indique le profil utilisé, l’action attendue et le résultat observé.

La checklist ci-dessous peut être intégrée telle quelle à votre dossier, en ajoutant une colonne « résultat » et une colonne « correction ». Si une vérification n’est pas possible faute de droits ou d’environnement, inscrivez « non testé » et expliquez pourquoi au lieu de présenter le contrôle comme réussi.

• Le titre et la page d’accueil expliquent-ils clairement l’usage du site de démonstration ?
• La navigation permet-elle de rejoindre la bibliothèque sans détour inutile ?
• Les colonnes ont-elles des noms compréhensibles et des valeurs cohérentes avec les fichiers fictifs ?
• Les vues affichent-elles les documents attendus et excluent-elles les contenus qui ne correspondent pas au filtre annoncé ?
• Un lecteur peut-il consulter les contenus prévus sans accéder à des fonctions de gestion non nécessaires ?
• Le gestionnaire peut-il ajouter ou mettre à jour un fichier et renseigner les propriétés attendues ?
• Les noms de fichiers, liens et propriétés sont-ils exempts de données confidentielles ou personnelles ?
• Les pages et documents restent-ils lisibles lors d’une navigation normale, avec une présentation suffisamment claire ?
• Les limites de version, de droits et de fonctions non testées sont-elles consignées dans la documentation ?
• Les captures et le scénario de démonstration montrent-ils un résultat fidèle à l’environnement réellement construit ?

Présenter son travail dans un portfolio

Présentez le projet comme une étude de cas courte : contexte fictif, besoin, périmètre, décisions, résultat, tests et limites. Commencez par le problème résolu, pas par l’énumération des menus SharePoint. Un recruteur ou un client doit pouvoir comprendre ce que vous avez construit et pourquoi cela aide les utilisateurs imaginés.

Choisissez quelques captures qui illustrent des éléments différents : l’accueil, la bibliothèque avec ses colonnes, une vue utile et, si cela a été réellement testé, un parcours associé aux droits. Avant de les partager, inspectez l’ensemble de l’image : adresse du site, nom de compte, menus, notifications, noms de fichiers et métadonnées. Floutez ou recadrez les éléments qui pourraient révéler une information ; mieux encore, réalisez les captures dans votre environnement fictif.

Ajoutez un schéma simple de navigation ou une fiche qui explique les colonnes et les rôles. Vous pouvez fournir une courte démonstration enregistrée si elle ne montre que des données fictives et si les règles de votre environnement l’autorisent. Une vidéo n’est pas indispensable : des captures lisibles accompagnées d’explications précises valent mieux qu’une démonstration longue et confuse.

Soyez exact sur votre contribution. Distinguez ce que vous avez réalisé, ce qui était déjà présent dans l’environnement, ce qui a été testé et ce qui reste une proposition. Mentionnez les contraintes rencontrées, comme l’absence d’un profil de test ou l’indisponibilité d’une fonction dans l’environnement. Cette transparence permet d’évaluer votre méthode sans donner une image trompeuse du résultat.

Pour conclure, indiquez ce que vous amélioreriez ensuite : tester l’espace avec de vrais utilisateurs autorisés, revoir les métadonnées après observation des usages ou étudier un processus de validation si les besoins et les droits le justifient. Présentez ces pistes comme des évolutions possibles, non comme des fonctionnalités déjà livrées.

• À publier : brief, captures anonymisées, schéma, checklist renseignée et résumé des décisions.
• À ne pas publier : identifiants, documents internes, noms de clients, URL privées, données personnelles ou captures provenant d’un environnement sans autorisation.
• À expliquer à l’oral : le besoin, les choix de classement, les tests réalisés, votre rôle exact et les limites du prototype.

Le parcours, étape par étape

1. 1Cadrer le besoin — Décrivez un problème documentaire fictif, les utilisateurs concernés et les critères de réussite. Limitez le projet à un site et à une bibliothèque principale.
2. 2Vérifier l’environnement — Confirmez la version de SharePoint Server, les fonctionnalités disponibles et les droits autorisés. Consignez ce que vous ne pouvez pas tester.
3. 3Préparer les contenus — Créez des documents et des métadonnées fictifs. Écartez toute donnée personnelle, interne ou protégée.
4. 4Construire l’espace — Créez le site, la page d’accueil, la bibliothèque, les colonnes et des vues correspondant aux usages décrits dans le brief.
5. 5Tester et corriger — Suivez la checklist avec des tâches réalistes. Corrigez les incohérences et signalez explicitement les contrôles non effectués.
6. 6Documenter et présenter — Préparez des captures expurgées, un schéma, les livrables et une explication honnête de votre contribution et des limites.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. Formation intra-entreprise — OFPPT ofppt.ma
2. JobInTech jobintech.academy
3. FormaGroup — SharePoint Server formagroup.ma