Créer un projet de portfolio avec Creatio au Maroc : du brief à la démonstration

Choisir un projet adapté à son niveau

Le projet doit être assez concret pour raconter une histoire métier, mais assez restreint pour être terminé et testé. Pour un premier exercice pratique Creatio, évitez de vouloir couvrir toute l’activité d’une entreprise. Choisissez plutôt un parcours identifiable, avec un point de départ, quelques étapes et un résultat attendu. Un suivi de demandes de service convient bien : une demande est enregistrée, affectée, suivie, puis clôturée.

Avant de commencer, vérifiez que votre idée répond à trois questions. Qui utilisera l’application ? Quelle difficulté cherche-t-elle à résoudre ? Quel résultat pourra-t-on observer dans Creatio ? Par exemple, une petite équipe de support doit savoir quelles demandes sont ouvertes, qui en est responsable et lesquelles nécessitent une réponse prioritaire. Ce besoin donne un fil conducteur aux données, à l’interface et aux tests.

Ajustez la complexité à votre expérience. Une personne débutante peut se limiter à un objet de demande, à quelques champs, à des statuts et à une vue de suivi. Avec davantage d’expérience, on peut ajouter des règles d’affectation, des alertes ou des indicateurs, à condition de les expliquer et de les tester. N’ajoutez pas une fonction simplement parce qu’elle est disponible : elle doit servir le besoin décrit.

Gardez une définition de réussite observable. Par exemple : un utilisateur peut créer une demande, retrouver les demandes ouvertes et faire progresser une demande jusqu’à sa clôture. Cette définition permet de décider quoi construire et quand s’arrêter. Elle évite aussi de confondre un projet bien présenté avec une application nécessairement complexe.

• Périmètre conseillé : un processus métier, un type d’enregistrement et quelques rôles d’utilisateur.
• Résultat attendu : une personne qui découvre le projet comprend le besoin et peut suivre une demande de bout en bout.
• À éviter au début : les données réelles, les intégrations externes indispensables à la démonstration et les fonctionnalités sans lien avec l’objectif.

Partir d’un besoin concret

Un projet de portfolio gagne en crédibilité quand il commence par une situation compréhensible. Vous pouvez imaginer une petite entreprise qui reçoit des demandes de clients par plusieurs canaux et qui souhaite éviter les oublis. Présentez ce scénario comme une hypothèse de conception, et non comme un témoignage réel ou une mission effectuée si ce n’est pas le cas.

Décrivez le parcours actuel en quelques lignes : une demande arrive, une personne la qualifie, elle est attribuée à un responsable, une réponse est préparée et le dossier est clos. Puis indiquez le problème ciblé, par exemple le manque de visibilité sur les demandes en cours. Votre application ne doit pas prétendre résoudre tous les problèmes de service client ; elle doit démontrer comment un processus précis pourrait être organisé.

Rédigez un brief avant d’ouvrir l’outil. Il servira de référence lorsque vous aurez à faire des choix de configuration ou à expliquer le résultat à un recruteur ou à un client.

• Brief de projet — objectif : concevoir une application de démonstration permettant d’enregistrer et de suivre des demandes de service jusqu’à leur clôture.
• Utilisateurs envisagés : une personne qui traite les demandes et une personne qui supervise leur suivi.
• Fonctions retenues : création d’une demande, saisie de ses informations essentielles, suivi de son statut, identification de son responsable et consultation des demandes en cours.
• Livrables : application ou environnement de démonstration Creatio, schéma simple du processus, description des données et des choix de conception, checklist de tests, captures d’écran et courte démonstration.
• Limites déclarées : données fictives ; pas de connexion à un système client ; pas de promesse sur des fonctions ou résultats qui n’ont pas été testés.

Préparer les données, fichiers ou ressources

Avant la configuration, listez les informations nécessaires au processus. Pour une demande de service, un modèle raisonnable peut inclure une référence fictive, un sujet, une description, une catégorie, une priorité, un statut, une date de création et un responsable fictif. Ne collectez que les champs utiles à la démonstration. Un champ supplémentaire rend le projet plus difficile à expliquer et à vérifier.

Préparez quelques enregistrements inventés, couvrant des situations différentes : une demande nouvelle, une demande en cours et une demande clôturée. Utilisez des noms et coordonnées manifestement fictifs. N’importez pas un fichier récupéré dans une entreprise, un ancien emploi ou un stage, même si vous pensez que les personnes concernées ne sont pas identifiables.

Rassemblez également les ressources de présentation : le brief, un schéma du parcours, la liste des champs, les scénarios de test et, si nécessaire, des icônes ou illustrations que vous avez le droit d’utiliser. Conservez vos notes de conception dans un document séparé. Elles vous aideront à expliquer pourquoi vous avez retenu un champ, un statut ou une règle.

Pensez à l’accès et à la diffusion dès le départ. Un portfolio public peut être consulté et copié par des tiers. N’y placez pas d’identifiants, de données de connexion, de documents internes, de noms de clients, de conversations réelles ou d’informations obtenues sous accord de confidentialité. Si une capture montre un élément sensible, refaites-la avec un environnement fictif plutôt que de compter uniquement sur un floutage.

• À préparer : brief, modèle de données minimal, enregistrements fictifs, parcours métier et scénarios de test.
• À exclure : données personnelles réelles, fichiers d’entreprise, captures d’un environnement de travail et identifiants.
• À vérifier : droits d’utilisation des visuels et autorisation de partager chaque ressource intégrée au portfolio.

Réaliser le projet par étapes

Commencez par traduire le brief en parcours. Notez ce qui se passe lorsqu’une demande arrive, qui agit à chaque étape et comment le dossier est considéré comme terminé. Un schéma simple avec quelques états suffit pour communiquer l’idée. Faites ensuite correspondre chaque étape à une information ou une action utile dans l’application.

Créez ou configurez le type d’enregistrement correspondant à une demande. Ajoutez les champs retenus dans le brief, en donnant aux libellés des noms compréhensibles pour un utilisateur métier. Organisez ensuite une fiche de demande afin que les informations importantes soient faciles à repérer. Gardez la même logique dans les vues de liste et dans les filtres.

Configurez les étapes de suivi retenues, par exemple « Nouvelle », « En cours » et « Clôturée ». Les noms doivent décrire clairement l’état du travail. Si vous ajoutez une règle — comme demander un responsable avant de clôturer — écrivez-la dans vos notes et prévoyez un test dédié. Ne présentez pas une règle comme fonctionnelle tant que vous ne l’avez pas vérifiée dans l’environnement utilisé.

Préparez une vue de suivi qui aide à répondre à une question concrète : quelles demandes restent ouvertes ? Si votre version ou votre configuration permet d’afficher un indicateur supplémentaire, expliquez ce qu’il mesure et sur quelles données il repose. Un résultat simple et cohérent est plus convaincant qu’un tableau de bord chargé sans objectif clair.

Enfin, répétez le parcours complet avec vos données fictives : créer une demande, la retrouver, modifier les informations prévues, la faire avancer et la clôturer. Prenez des notes sur les étapes qui nécessitent une précision supplémentaire. Cette répétition révèle les problèmes de libellé, de logique ou de navigation avant la présentation.

• Étape 1 : relire le brief et dessiner le processus.
• Étape 2 : définir les enregistrements, champs et valeurs autorisées.
• Étape 3 : configurer la fiche et les vues utiles au parcours.
• Étape 4 : mettre en place les statuts et les règles retenus, puis les tester.
• Étape 5 : préparer une vue de suivi et vérifier qu’elle répond au besoin annoncé.
• Étape 6 : parcourir le scénario complet avec des données entièrement fictives.

Tester, corriger et documenter

Les tests montrent que vous savez contrôler le fonctionnement, et pas seulement configurer une interface. Pour chaque scénario, écrivez l’action à effectuer et le résultat attendu. Si le résultat diffère, corrigez la configuration ou indiquez honnêtement la limite. N’affirmez pas qu’une application a été validée par de vrais utilisateurs si vous n’avez pas mené cette validation.

Après chaque série de tests, vérifiez aussi la cohérence des données et la compréhension des libellés. Une personne qui découvre votre démonstration devrait pouvoir distinguer rapidement une demande nouvelle d’une demande terminée. Si un terme métier est nécessaire, expliquez-le dans la documentation.

Votre documentation peut rester courte : objectif, utilisateurs visés, schéma du processus, description des champs, règles de fonctionnement, résultats des tests et limites connues. Ajoutez une note précisant que les données sont fictives et que le projet est une démonstration, si c’est le cas. Cette transparence aide le lecteur à évaluer votre travail sans lui attribuer une portée qu’il n’a pas.

• Checklist de tests et de contrôle qualité :
• Le formulaire permet-il de créer une demande avec les informations prévues ?
• Les champs essentiels sont-ils clairement nommés et les valeurs faciles à comprendre ?
• Une demande peut-elle être retrouvée dans la vue ou le filtre prévu ?
• Les changements de statut correspondent-ils au parcours décrit ?
• Une règle de configuration annoncée fonctionne-t-elle dans les cas testés ?
• Une demande clôturée se distingue-t-elle clairement d’une demande encore ouverte ?
• Les enregistrements de démonstration sont-ils fictifs et dépourvus de données sensibles ?
• Les captures et documents ne montrent-ils ni identifiants, ni coordonnées réelles, ni information confidentielle ?
• La démonstration suit-elle un scénario cohérent et se termine-t-elle par le résultat annoncé ?

Présenter son travail dans un portfolio

Présentez le projet dans l’ordre où un lecteur peut le comprendre : le besoin, votre réponse, le parcours construit, les tests et les limites. Commencez par un résumé en quelques phrases. Précisez le rôle que vous avez tenu, les éléments que vous avez réellement configurés et les outils que vous avez réellement utilisés. Si le travail est un exercice personnel, dites-le clairement.

Choisissez quelques captures lisibles plutôt qu’une longue galerie. Une fiche de demande avec des données fictives, une vue de suivi et un aperçu des étapes du processus peuvent suffire à raconter le fonctionnement. Ajoutez une légende à chaque image : ce qu’elle montre et en quoi cela répond au besoin. Vérifiez la taille du texte et recadrez les éléments inutiles, sans masquer une information sensible après coup.

Si vous présentez une démonstration vidéo, utilisez un environnement préparé à l’avance et un scénario court. Montrez une demande fictive, faites-la progresser et expliquez le résultat. Ne laissez pas apparaître de menu, de notification ou de donnée provenant d’un compte professionnel. Une démonstration reproductible est plus utile qu’une présentation spectaculaire difficile à vérifier.

Terminez par une rubrique « limites et suites possibles ». Vous pouvez y préciser que le projet ne comporte pas d’intégration à un outil externe, qu’il utilise uniquement des exemples inventés ou qu’une vérification par utilisateurs reste à faire. Proposez ensuite une amélioration raisonnable, par exemple clarifier une règle de priorité ou ajouter un scénario de test. Présenter les limites sans les dissimuler renforce la crédibilité du portfolio.

• À montrer : le problème, le processus, la configuration utile, les résultats des tests et les livrables.
• À préciser : exercice ou expérience réelle, contribution personnelle, environnement utilisé et limites vérifiées.
• À ne pas publier : données confidentielles, informations personnelles, identifiants ou captures d’un système auquel vous n’êtes pas autorisé à donner accès.

Le parcours, étape par étape

1. 11. Cadrer le besoin — Choisissez un cas métier limité et rédigez le brief : objectif, utilisateurs, fonctions retenues, livrables et limites.
2. 22. Préparer un scénario fictif — Définissez quelques demandes inventées, le modèle de données minimal et les différentes étapes du processus.
3. 33. Configurer Creatio — Créez les enregistrements et vues nécessaires au parcours, puis ajoutez uniquement les règles qui servent l’objectif annoncé.
4. 44. Tester le parcours — Exécutez des scénarios de création, de recherche, de mise à jour et de clôture. Corrigez les incohérences et notez les limites.
5. 55. Constituer le portfolio — Rassemblez le brief, les captures anonymes, la documentation et une démonstration courte. Indiquez clairement ce qui a été réalisé et vérifié.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. FormaGroup — formations Creatio formagroup.ma
2. JobInTech jobintech.academy
3. OFPPT — Formation intra-entreprise ofppt.ma
4. Creatio Academy academy.creatio.com