Oracle PeopleSoft au Maroc : créez un projet concret pour votre portfolio

Choisir un projet adapté à son niveau

Un projet Oracle PeopleSoft débutant doit être assez limité pour être terminé, mais assez concret pour faire apparaître votre raisonnement. Évitez de vouloir couvrir simultanément les ressources humaines, la finance, la sécurité et les intégrations. Choisissez un seul processus, un seul type d’utilisateur principal et un résultat que vous pouvez expliquer en quelques minutes.

Un bon sujet de portfolio peut porter sur une demande de formation interne : un salarié soumet une demande, un responsable la examine, puis l’équipe administrative suit son statut. Ce scénario est facile à comprendre pour un recruteur, tout en permettant de travailler sur les besoins métier, les rôles, les règles de validation, les données et les contrôles. Il ne faut toutefois pas le présenter comme une fonctionnalité PeopleSoft standard ou comme une configuration réelle si vous ne l’avez pas effectivement réalisée dans un environnement autorisé.

Adaptez les livrables à votre niveau. Un profil fonctionnel peut produire le processus cible, les exigences, les règles de gestion et les cas de test. Un profil technique peut détailler, dans le périmètre effectivement accessible, les objets ou éléments PeopleTools qu’il a réalisés et expliquer leur rôle. Un profil en reconversion peut commencer par un dossier de conception complet et une maquette non connectée, en signalant clairement qu’il s’agit d’un prototype.

• Choisissez un processus métier unique, avec un début et une fin identifiables.
• Fixez une limite de périmètre : par exemple, demande, approbation et suivi, sans paie ni intégration comptable.
• Précisez ce qui est réellement construit, ce qui est simulé et ce qui reste hors périmètre.
• Prévoyez un environnement de pratique autorisé avant toute manipulation du logiciel.

Partir d’un besoin concret

Commencez par décrire une difficulté observable : les demandes de formation arrivent par plusieurs canaux, leur statut est difficile à connaître et les responsables ne disposent pas d’une vue cohérente. Le projet ne cherche pas à affirmer que toutes les entreprises marocaines rencontrent ce problème ; il pose un cas fictif, suffisamment réaliste pour cadrer un exercice.

Transformez le problème en objectif mesurable dans le cadre du projet, sans inventer de gain chiffré. Par exemple : « concevoir un processus permettant de saisir une demande, d’enregistrer une décision et de consulter son état ». Définissez ensuite les utilisateurs concernés : demandeur, responsable approbateur et personne chargée du suivi administratif. Pour chacun, formulez les informations nécessaires et les actions autorisées.

Voici un brief que vous pouvez reprendre et adapter :

Le scénario doit rester honnête. Si vous travaillez à partir d’un exemple pédagogique, dites-le. Si vous avez réalisé une mission réelle, obtenez l’autorisation de présenter les éléments et remplacez les détails identifiants. Une description du besoin et des règles de gestion peut démontrer votre compréhension sans révéler les noms, procédures ou paramètres internes d’une organisation.

• Objectif : concevoir un suivi clair des demandes de formation, de leur soumission à leur décision.
• Livrables : description du processus, exigences fonctionnelles, modèle de données fictif, règles de validation, cas de test et courte présentation.
• Périmètre : demandes et décisions uniquement ; les inscriptions réelles, paiements, paie et intégrations sont exclus.
• Critère de réussite : un tiers peut comprendre le parcours, les rôles, les données utilisées et les limites du prototype.

Préparer les données, fichiers ou ressources

Avant de commencer, établissez une liste des ressources nécessaires. Il vous faut le brief, un schéma simple du processus, un jeu de données fictif, une liste de règles et un espace où conserver vos livrables. Si un accès à PeopleSoft est requis pour votre objectif, vérifiez auprès de l’organisation ou du fournisseur de formation que cet accès est autorisé et adapté à la pratique.

Préparez quelques demandes fictives avec des valeurs génériques : identifiant non réel, intitulé de formation inventé, date, statut et décision. N’utilisez ni données personnelles, ni informations d’entreprise, ni export de base de données. Les captures d’écran peuvent révéler des noms, des adresses, des identifiants, des URL internes ou des éléments de configuration : inspectez-les et masquez tout contenu sensible avant de les partager.

Listez également les hypothèses : qui peut soumettre une demande, qui peut la valider, quels statuts sont possibles et que se passe-t-il si une demande est incomplète ? Les hypothèses ne sont pas des faits sur un déploiement PeopleSoft particulier. Présentez-les comme des choix de conception propres à votre exercice.

Si vous n’avez pas d’accès à un environnement PeopleSoft, vous pouvez réaliser une partie importante du travail sous forme de spécifications, schémas, maquette et plan de test. Dans ce cas, ne décrivez pas une maquette comme une transaction exécutée dans PeopleSoft. Cette distinction rend le portfolio plus crédible.

• Un document de brief et un diagramme du processus.
• Des données fictives, sans nom, adresse, matricule ou information tirée d’un système réel.
• Une liste des rôles, des statuts et des règles de gestion.
• Un environnement de test autorisé si vous construisez ou exécutez des éléments dans PeopleSoft.
• Une vérification de confidentialité avant chaque capture, export ou partage.

Réaliser le projet par étapes

La réalisation doit suivre une progression lisible. Dans un contexte PeopleSoft, les tâches exactes dépendent de votre rôle, de l’environnement disponible et des droits accordés. Il vaut mieux nommer seulement les éléments que vous avez effectivement manipulés que d’ajouter des termes techniques pour impressionner. Si vous utilisez des composants de PeopleTools ou d’autres fonctions PeopleSoft, expliquez leur usage dans votre projet et distinguez-le des parties simulées.

• Décrire le processus actuel fictif et le résultat attendu. Écrivez une courte histoire utilisateur pour le demandeur et pour l’approbateur.
• Transformer les besoins en exigences vérifiables : les champs à saisir, les contrôles attendus, les statuts possibles et les actions autorisées.
• Établir le modèle des informations. Définissez les données indispensables à votre scénario et justifiez les champs retenus. Évitez de collecter des informations sans utilité pour l’exercice.
• Décrire les rôles et leurs permissions. Vérifiez que le demandeur et l’approbateur n’effectuent pas les mêmes actions dans votre conception.
• Construire le prototype dans un environnement PeopleSoft autorisé, si vous en avez un et si le périmètre le permet. Sinon, préparer une maquette et des spécifications ; indiquez explicitement que l’exécution dans PeopleSoft n’a pas été réalisée.
• Préparer les cas de test à partir des exigences, puis exécuter uniquement ceux que votre environnement permet réellement de tester. Notez le résultat observé et les défauts corrigés.
• Préparer une démonstration courte : besoin, parcours, résultat, contrôles et limites. Répétez-la avec les données fictives destinées au portfolio.

Tester, corriger et documenter

Une démonstration fluide ne suffit pas à prouver que le projet est bien contrôlé. Préparez des vérifications positives et négatives : une demande complète, un champ obligatoire manquant, une décision enregistrée par le bon rôle et une tentative d’action qui ne devrait pas être autorisée. Si une fonction n’est qu’une hypothèse ou une maquette, présentez le cas de test comme prévu ou simulé, pas comme réussi dans PeopleSoft.

Consignez les anomalies de manière reproductible : numéro du cas, résultat attendu, résultat observé, statut et correction apportée. Cette trace permet à un autre lecteur de comprendre votre démarche et vous aide à éviter des affirmations vagues comme « tout fonctionne ».

Documentez aussi vos décisions : pourquoi tel statut existe, pourquoi un champ est nécessaire, quels cas ne sont pas couverts et quelles informations restent à clarifier dans une vraie entreprise. Une bonne documentation indique les limites au lieu de masquer les parties non réalisées.

• Le parcours normal peut-il être expliqué du dépôt de la demande jusqu’à la décision ?
• Les champs requis sont-ils identifiés et les demandes incomplètes traitées selon une règle documentée ?
• Les rôles et actions autorisées sont-ils cohérents dans la conception ou dans le prototype ?
• Les statuts, décisions et résultats sont-ils compréhensibles pour un utilisateur non technique ?
• Les tests distinguent-ils les contrôles réellement exécutés des contrôles seulement prévus ?
• Les captures, fichiers et exemples ont-ils été examinés pour retirer les données sensibles ?
• Les limites, hypothèses, corrections et éléments hors périmètre sont-ils clairement écrits ?

Présenter son travail dans un portfolio

Organisez le portfolio autour d’une page de synthèse : contexte fictif ou autorisé, problème, objectif, votre contribution, livrables et limites. Ajoutez ensuite un schéma du processus, quelques exigences, un extrait du jeu de données fictif et les résultats de tests. Le lecteur doit distinguer en un coup d’œil la conception, la maquette et les éléments effectivement réalisés dans PeopleSoft.

Sélectionnez peu de captures, mais légendez chacune : ce qu’elle illustre et à quelle étape elle correspond. Avant publication, vérifiez qu’elles ne montrent aucun nom réel, identifiant, courriel, adresse de serveur, donnée d’entreprise ou écran auquel vous n’êtes pas autorisé à donner accès. Quand une capture n’est pas nécessaire, préférez un schéma recréé avec des données fictives.

Dans une présentation orale ou un entretien, commencez par le besoin métier et faites ensuite le lien avec les décisions fonctionnelles ou techniques. Soyez précis sur votre rôle : travail individuel, exercice encadré ou contribution en équipe. Indiquez également les fonctionnalités non réalisées et ce que vous feriez ensuite, par exemple approfondir les tests ou valider les règles avec un utilisateur métier.

• Une page de synthèse et un schéma lisible du parcours.
• Des livrables courts : exigences, règles, modèle de données fictif et cas de test.
• Des captures anonymisées seulement si elles apportent une preuve utile.
• Une démonstration courte, préparée sur un scénario fictif.
• Une rubrique « limites et prochaines étapes » qui sépare clairement le réalisé du projeté.

Le parcours, étape par étape

1. 1Cadrer — Choisissez le processus de demande de formation, définissez le problème, les utilisateurs, l’objectif et les exclusions du projet.
2. 2Concevoir — Rédigez les exigences, les règles de validation, les rôles et le modèle de données fictif. Marquez les hypothèses comme telles.
3. 3Construire ou simuler — Dans un environnement autorisé, réalisez uniquement les éléments que vous maîtrisez et pouvez décrire. Sans accès PeopleSoft, préparez une maquette et des spécifications, sans revendiquer une réalisation dans l’outil.
4. 4Tester — Exécutez les contrôles possibles, consignez les résultats et corrigez les problèmes. Distinguez les tests exécutés des scénarios non testés.
5. 5Documenter et présenter — Assemblez les livrables, retirez les informations confidentielles, précisez votre contribution et préparez une démonstration concise.

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. Oracle oracle.com
4. FormaGroup — Oracle PeopleSoft formagroup.ma