Créer un projet de portfolio Erlang/OTP au Maroc : du brief à la démonstration

Choisir un projet Erlang/OTP adapté à son niveau

Pour un projet Erlang/OTP débutant, choisissez une réalisation qui peut être décrite en une phrase et dont le résultat se vérifie facilement. Une application trop vaste risque de rester inachevée ; une simple suite d’exercices, à l’inverse, ne montre pas toujours comment vous organisez un programme complet. Le bon compromis est un petit service avec une responsabilité claire, quelques comportements utiles et une documentation suffisante pour qu’une autre personne puisse le lancer.

L’exemple de ce guide est une file de tâches locale. Une personne peut soumettre une tâche, consulter son état, puis voir si elle est terminée ou a échoué. La première version peut traiter des tâches simulées en mémoire. Elle n’a pas besoin d’un tableau de bord, d’un compte utilisateur, d’une base de données ou d’un déploiement dans le cloud. Ces ajouts peuvent être envisagés plus tard, si le noyau du projet est déjà fiable.

Fixez dès le départ des critères d’achèvement : le projet démarre depuis un dépôt neuf en suivant les instructions, accepte une petite série de tâches, expose leur état et dispose de tests automatisés. Ajoutez un critère de qualité : une panne simulée doit être observable et ne doit pas faire disparaître silencieusement toute l’application. Cette portée permet de montrer des compétences Erlang/OTP sans laisser entendre que le projet offre les garanties d’un service réellement exploité.

• Définissez un public : par exemple, un développeur qui veut comprendre le fonctionnement d’une file de traitement.
• Choisissez une seule interface initiale : commandes dans le terminal, ou API HTTP simple si vous maîtrisez déjà cette partie.
• Limitez les fonctions : soumettre, consulter, terminer ou échouer une tâche, et afficher un état.
• Écrivez ce qui ne sera pas inclus : authentification, paiement, données réelles et disponibilité de production.

Partir d’un besoin concret

Un projet convaincant répond à une difficulté reconnaissable. Dans une petite équipe, certaines opérations peuvent être longues : génération d’un rapport, traitement d’un lot de fichiers ou vérification périodique d’une ressource. Si l’opération est lancée directement dans une interface, un retard ou une erreur peut rendre le suivi difficile. Une file de tâches aide à séparer la demande de son traitement et à rendre l’avancement visible.

Pour rester réaliste et prudent, le projet de portfolio ne doit pas se connecter à un service d’entreprise ni traiter des dossiers de clients. Simulez le travail avec une fonction qui attend un court délai, renvoie un résultat déterministe ou produit une erreur contrôlée. Ainsi, la démonstration porte sur l’organisation du système, et non sur des données ou accès qui ne vous appartiennent pas.

Avant de coder, rédigez un brief court. Il rend votre objectif vérifiable et aide un recruteur ou un client à comprendre pourquoi le projet existe.

• Brief — objectif : créer un service Erlang/OTP qui reçoit des tâches simulées, les traite de façon asynchrone et permet de consulter leur état.
• Utilisateurs visés : une personne qui soumet une tâche et une personne technique qui observe le service.
• Fonctions attendues : création d’une tâche, identifiant, état lisible, traitement simulé, résultat ou erreur compréhensible.
• Livrables : dépôt de code, instructions de lancement, tests, schéma de l’architecture, exemples de commandes ou de requêtes, courte démonstration et liste des limites.
• Critère de réussite : une autre personne peut suivre les consignes, reproduire le scénario normal et vérifier le scénario d’erreur.

Préparer les données, fichiers ou ressources

Un petit inventaire avant le démarrage évite de perdre du temps sur des dépendances, des données ou des accès difficiles à obtenir. Pour ce projet, privilégiez les ressources que vous pouvez créer vous-même : exemples de tâches fictives, résultats simulés, configuration locale et scripts de lancement. N’incluez ni export interne, ni identifiant d’accès, ni journal provenant d’un environnement professionnel.

Préparez un dépôt propre avec le code source, une configuration d’exemple et les fichiers nécessaires aux tests. Les valeurs propres à votre machine — chemins privés, jetons d’accès, mots de passe — ne doivent pas être commitées. Si une configuration est nécessaire, fournissez un modèle sans secret et expliquez comment créer une configuration locale.

Choisissez une version de l’environnement et des dépendances compatible avec votre installation, puis notez-la dans la documentation. Les détails de versions et de commandes peuvent évoluer : vérifiez-les dans la documentation officielle au moment où vous commencez, plutôt que de copier aveuglément une ancienne consigne.

• Données : quelques tâches inventées, avec des entrées valides, invalides et volontairement en erreur.
• Fichiers : code source, configuration d’exemple, scripts utiles, tests et fichier de présentation du projet.
• Accès : aucun accès de production requis ; si une démonstration utilise un service externe, choisissez un environnement de test autorisé.
• Confidentialité : vérifiez l’historique du dépôt, les captures d’écran, les journaux et les exemples de configuration avant publication.

Réaliser le projet par étapes

Avancez par tranches fonctionnelles. Après chaque tranche, gardez le projet dans un état lançable et notez ce que vous avez vérifié. Erlang/OTP fournit des mécanismes pour structurer des applications concurrentes et superviser des processus ; dans un portfolio, l’important est d’expliquer pourquoi vous les utilisez et ce qu’ils apportent à ce périmètre limité.

Commencez par le comportement visible, puis séparez progressivement les responsabilités. Évitez de multiplier les processus ou les abstractions simplement pour donner une impression de complexité. Votre code sera plus convaincant si chaque composant a une raison d’être claire et si le parcours d’une tâche est facile à suivre.

• Initialisez le dépôt et rédigez le brief, les critères de réussite et les limites du projet.
• Créez une première version qui accepte une tâche fictive et renvoie un identifiant ainsi qu’un état.
• Définissez les états possibles — par exemple en attente, en cours, terminée ou en erreur — et les transitions autorisées.
• Ajoutez le traitement simulé et la consultation de l’état ; rendez les erreurs visibles sans exposer de détails sensibles.
• Structurez l’application avec les comportements OTP pertinents. Expliquez le rôle des processus et de la supervision dans le README.
• Ajoutez une interface en ligne de commande ou une API simple seulement si elle sert la démonstration et reste dans le temps prévu.
• Automatisez les tests, corrigez les cas limites, puis préparez les commandes de lancement et une démonstration reproductible.

Tester, corriger et documenter

Les tests doivent prouver des comportements précis, pas seulement confirmer que le programme démarre. Prévoyez des scénarios normaux, des entrées incorrectes, des erreurs de traitement et des redémarrages adaptés à ce que votre application prétend faire. Si une propriété de reprise ou de persistance n’est pas implémentée, dites-le explicitement au lieu de laisser entendre qu’elle est garantie.

Pour la documentation, partez de la personne qui découvre le dépôt. Indiquez le problème visé, les prérequis, les commandes de lancement, la façon d’exécuter les tests et un exemple de résultat attendu. Ajoutez un schéma léger montrant les composants et leurs échanges. Une explication courte de vos choix — et des alternatives écartées — vaut mieux qu’une description remplie de termes techniques.

Avant de publier, faites une revue de confidentialité. Remplacez les noms, adresses, identifiants et contenus professionnels par des exemples fictifs. Vérifiez aussi que les captures et les journaux ne révèlent pas de secrets. Si le projet s’inspire d’une mission réelle, décrivez le type de problème en termes généraux et ne publiez que ce que vous êtes autorisé à partager.

• Démarrage : l’application peut-elle être lancée depuis un dépôt fraîchement récupéré en suivant uniquement le README ?
• Fonctionnel : la création, la consultation et la mise à jour d’une tâche donnent-elles le résultat attendu ?
• Entrées : les données manquantes ou incorrectes sont-elles rejetées ou signalées clairement ?
• Erreurs : le scénario d’échec simulé est-il visible et traité comme prévu ?
• Processus : les composants importants démarrent-ils et les erreurs de processus sont-elles observables ?
• Tests : les tests automatisés couvrent-ils les parcours normaux et les cas limites annoncés ?
• Qualité : le code est-il lisible, les noms cohérents et les instructions de test à jour ?
• Confidentialité : le dépôt, son historique, les captures et les journaux ne contiennent-ils aucune donnée sensible ?
• Honnêteté : les limites, fonctions simulées et éléments non réalisés sont-ils clairement signalés ?

Présenter son travail dans un portfolio

Présentez le projet comme un parcours compréhensible : le besoin, le périmètre retenu, le fonctionnement, les contrôles réalisés et les prochaines améliorations possibles. Une capture du terminal ou une courte démonstration peut aider, mais elle ne remplace pas un dépôt lisible et des instructions que la personne qui évalue peut suivre elle-même.

Mettez en avant votre contribution exacte. Si vous avez travaillé en équipe, distinguez ce que vous avez conçu, codé, testé ou documenté. Si l’interface est simulée, dites-le. Si le service fonctionne uniquement en local ou conserve les tâches en mémoire, indiquez-le également. Présenter honnêtement ces limites rend votre travail plus facile à évaluer.

Pour un portfolio Erlang/OTP, montrez surtout que vous savez relier un besoin à une conception, raisonner sur les erreurs et rendre votre réalisation vérifiable. Un projet modeste, terminé et bien expliqué peut être plus parlant qu’une liste de fonctions ambitieuses sans tests ni démonstration.

• Un résumé d’une phrase et le problème auquel le projet répond.
• Une image ou une courte démonstration construite avec des données fictives.
• Un schéma des composants et une explication des choix Erlang/OTP.
• Les instructions de lancement, les tests et un exemple de scénario normal et d’échec.
• Une rubrique « limites et suites possibles » qui distingue clairement l’existant des idées futures.

Le parcours, étape par étape

1. 1Cadrer le projet — Rédigez le brief, identifiez le public, fixez les fonctions indispensables et notez les exclusions. Le résultat doit pouvoir être démontré sans données professionnelles.
2. 2Préparer un environnement reproductible — Créez le dépôt, choisissez les outils adaptés et vérifiez les instructions officielles pour les versions et commandes utilisées. Ajoutez une configuration d’exemple sans secrets.
3. 3Construire le parcours d’une tâche — Implémentez la soumission, l’identifiant, les états et la consultation. Utilisez des données fictives et rendez les erreurs compréhensibles.
4. 4Structurer avec OTP — Organisez les composants et processus nécessaires au périmètre. Ajoutez une supervision pertinente et documentez ce qu’elle fait, sans promettre de garanties non implémentées.
5. 5Tester et contrôler — Couvrez les scénarios normaux, les entrées invalides et les erreurs simulées. Rejouez les instructions depuis un environnement propre et vérifiez la confidentialité du dépôt.
6. 6Préparer la présentation — Ajoutez un README, un schéma, des captures ou une démonstration, puis indiquez les limites et votre contribution exacte. Demandez à une autre personne de suivre les consignes.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. FormaGroup — Technologie Erlang/OTP formagroup.ma
2. Documentation Erlang/OTP erlang.org
3. JobInTech jobintech.academy
4. Formation intra-entreprise — OFPPT ofppt.ma