Créer un portfolio LangGraph au Maroc : un projet concret, du brief à la démo

Choisir un projet adapté à son niveau

Le meilleur projet LangGraph pour débuter est assez petit pour être terminé, mais assez riche pour montrer plusieurs compétences. Un workflow de trois ou quatre étapes est souvent plus démonstratif qu’un agent prétendument autonome qui essaie de tout faire. Votre objectif est de faire comprendre votre raisonnement, pas d’accumuler des composants.

Choisissez un cas d’usage dont vous pouvez expliquer l’utilité en une phrase : « aider une équipe à trier des demandes entrantes et à préparer une réponse vérifiable ». Délimitez ensuite ce que le prototype fait et ne fait pas. Par exemple, il peut classer un message, rechercher une information dans un petit corpus documentaire et proposer un brouillon ; il ne l’envoie pas automatiquement et ne prend pas de décision sensible.

Pour un projet LangGraph débutant, une seule source de données, un nombre limité d’étapes et une interface simple suffisent. Une personne plus expérimentée peut ajouter une branche de traitement, une étape de validation humaine, des reprises après erreur ou une comparaison entre plusieurs stratégies. Dans tous les cas, chaque ajout doit servir un besoin identifiable.

• Choisir un problème compréhensible pour un métier ou une petite équipe.
• Définir un résultat observable : classement, brouillon, résumé ou recommandation à valider.
• Limiter le nombre de sources, d’outils et de cas particuliers pour la première version.
• Prévoir dès le départ une sortie claire quand le système ne sait pas répondre.

Partir d’un besoin concret

Un exemple de projet concret LangGraph est un assistant de tri de demandes internes pour une équipe fictive de support. Il reçoit un message, identifie son thème, cherche les éléments pertinents dans une courte documentation publique ou créée pour le projet, puis prépare une réponse et indique les sources consultées. Si la confiance est insuffisante ou si la demande sort du périmètre, le workflow la signale pour examen humain.

Ce scénario permet de montrer des compétences variées sans présenter un système risqué comme une solution de production : structuration d’un workflow, gestion d’un état partagé, appels à un modèle ou à des fonctions, traitement de cas d’échec, contrôle des réponses et rédaction technique. Il est aussi facile à expliquer à un interlocuteur non spécialiste.

Avant de coder, écrivez un brief d’une page. Il doit répondre à quatre questions : qui rencontre le problème, quel travail répétitif le prototype cherche à faciliter, quelle entrée il reçoit et quel livrable il produit. Ajoutez des critères de réussite vérifiables, comme « les demandes hors périmètre sont signalées » ou « chaque réponse proposée renvoie aux documents utilisés ». Évitez une promesse vague telle que « automatiser le support ».

Présentez le projet comme un prototype pédagogique ou une preuve de concept. Si vous l’adaptez ensuite à une entreprise, le périmètre, les données, la sécurité et les modalités de validation devront être examinés avec les parties concernées.

• Objectif : aider une équipe fictive à organiser des demandes et à préparer des réponses documentées.
• Entrées : messages synthétiques et petit ensemble de documents autorisés.
• Traitement : classification, recherche documentaire, préparation d’un brouillon, contrôle et éventuelle escalade.
• Livrables : code, schéma du workflow, jeu d’essai non sensible, guide de lancement et courte démonstration.
• Hors périmètre : envoi automatique de messages et décisions à fort impact sans contrôle humain.

Préparer les données, fichiers ou ressources

Avant de créer le graphe, réunissez les éléments qui permettent de développer et de tester le projet sans dépendre d’informations privées. Vous pouvez rédiger quelques demandes fictives et une mini-FAQ originale, ou utiliser des documents publics dont les conditions autorisent l’usage prévu. Gardez une trace de la provenance des ressources et de leurs éventuelles limites.

N’intégrez pas dans un dépôt public des échanges clients, des noms, des coordonnées, des contrats, des documents internes ou des clés d’accès. Remplacez les exemples réels par des cas synthétiques. Si une organisation vous autorise à travailler sur ses données, clarifiez ce qui peut être stocké, partagé, anonymisé et montré dans votre portfolio ; l’autorisation de développer un prototype ne signifie pas nécessairement que vous pouvez en publier des extraits.

Préparez aussi l’environnement : version du langage et des dépendances, instructions d’installation, configuration d’exemple et variables d’environnement documentées. Les secrets doivent rester hors du code et des captures. Ajoutez un fichier d’exemple de configuration sans valeur confidentielle et expliquez comment le lecteur peut lancer une démonstration avec ses propres paramètres.

• Un petit corpus public ou fictif, cohérent avec le scénario.
• Des cas de test ordinaires, ambigus, incomplets et hors périmètre.
• Une description des sources et des règles d’utilisation des données.
• Un dépôt nettoyé de clés, jetons, historiques privés et fichiers personnels.
• Des instructions pour installer les dépendances et configurer le projet.

Réaliser le projet par étapes

Commencez par représenter le workflow avant de l’implémenter. Une version simple peut comporter un nœud de classification, un nœud de recherche, un nœud de rédaction et un nœud de contrôle. Des transitions dirigent ensuite la demande vers la réponse proposée, vers une demande de précision ou vers une revue humaine. La structure exacte dépend de votre conception ; le diagramme doit correspondre au code réellement exécuté.

Définissez l’état partagé avec les seules informations nécessaires : demande d’origine, catégorie, éléments retrouvés, brouillon, statut de validation et éventuels messages d’erreur. Distinguez les données d’entrée des résultats calculés. Cette étape vous oblige à réfléchir à ce que chaque composant reçoit et transmet, plutôt qu’à empiler des appels opaques.

Construisez d’abord un chemin nominal avec des fonctions simples et des sorties prévisibles. Ajoutez ensuite le modèle ou les outils nécessaires, puis vérifiez chaque transition. Le contrôle peut, par exemple, repérer l’absence de source, une demande hors périmètre ou une réponse vide. Pour un cas incertain, prévoyez une sortie explicite au lieu de forcer une réponse.

Enfin, ajoutez une interface minimale si elle aide à comprendre la démonstration. Un terminal, un notebook propre ou une petite interface peut convenir. L’interface n’est pas le cœur du projet : elle doit permettre au lecteur de lancer un cas et de voir les étapes, les sources retenues et la décision de contrôle.

• Écrire le brief et dessiner les nœuds ainsi que les transitions.
• Définir l’état du workflow et les formats d’entrée et de sortie.
• Implémenter un chemin nominal reproductible avec des données fictives.
• Ajouter les branches d’erreur, de clarification et de validation humaine utiles au scénario.
• Créer une démonstration courte qui suit un cas de bout en bout.

Tester, corriger et documenter

Un exercice pratique LangGraph prend de la valeur lorsque vous montrez comment vous avez vérifié son comportement. Testez les fonctions séparément, puis le workflow complet. N’évaluez pas seulement si une réponse paraît convaincante : vérifiez aussi que le graphe suit le bon chemin, que les informations attendues sont présentes et que les cas incertains ne sont pas présentés comme certains.

Notez les défauts observés et les corrections apportées. Un petit ensemble de cas bien choisis, décrit honnêtement, est plus utile qu’une affirmation générale de fiabilité. Si le résultat dépend d’un modèle externe, indiquez que les réponses peuvent varier selon la configuration et les données fournies. Ne publiez pas de chiffres de performance que vous n’avez pas mesurés selon une méthode expliquée.

• La demande ordinaire passe par les étapes attendues et produit une sortie compréhensible.
• Une demande incomplète déclenche une demande de précision ou une sortie appropriée.
• Une demande hors périmètre est signalée plutôt que traitée comme un cas standard.
• Une absence de document pertinent est visible et ne devient pas une source inventée.
• Une erreur de composant est gérée et expliquée sans exposer de secret.
• Les sources utilisées pour préparer la réponse sont affichées ou décrites.
• Le parcours de validation humaine fonctionne si le scénario en prévoit un.
• Les instructions du dépôt permettent à une autre personne de lancer le projet.

Présenter son travail dans un portfolio

Un portfolio LangGraph doit permettre à un recruteur ou à un client de comprendre rapidement le problème, votre contribution et le résultat. Préparez un dépôt lisible, un schéma fidèle au workflow, quelques captures ou une courte démonstration et une explication des choix techniques. Indiquez les prérequis et les étapes pour reproduire un cas, sans obliger le lecteur à deviner la configuration.

Dans la présentation, montrez un exemple représentatif, puis un cas où le système refuse de répondre ou demande une intervention. Cette seconde démonstration rend visibles vos réflexes de qualité et votre compréhension des limites. Expliquez ce qui est automatisé, ce qui reste contrôlé par une personne et ce qui devrait être renforcé avant tout usage réel.

Retirez des captures les noms, adresses, historiques, jetons et informations d’environnement. Vérifiez aussi les journaux, les fichiers de démonstration et l’historique du dépôt : une donnée supprimée de l’écran peut rester présente dans un fichier ou une ancienne version. Si vous vous êtes inspiré d’un contexte professionnel, décrivez le besoin de manière générale et n’attribuez pas à une organisation un résultat ou une autorisation qui n’a pas été confirmé.

Pour rendre le projet plus convaincant, terminez par une courte section « prochaines améliorations » : élargir le jeu de tests, améliorer la gestion des erreurs, examiner la protection des données ou évaluer la qualité avec des critères définis. Une suite de travail réaliste montre que vous savez distinguer une démonstration de portfolio d’un produit prêt à être déployé.

• Un résumé du besoin, des utilisateurs visés et du périmètre.
• Un schéma du graphe et une explication concise de l’état partagé.
• Une démonstration avec un cas nominal et un cas limite.
• Des consignes de reproduction et un aperçu des tests effectués.
• Une présentation transparente des limites et des améliorations envisagées.
• Aucune donnée confidentielle, aucun secret et aucune promesse de résultat non vérifiée.

Le parcours, étape par étape

1. 11. Définir le cas d’usage — Choisissez un problème limité et rédigez un brief précisant l’objectif, les utilisateurs, les entrées, les sorties et ce qui reste hors périmètre.
2. 22. Préparer des ressources sûres — Constituez un corpus fictif ou autorisé, des exemples variés et un environnement reproductible. Excluez les informations sensibles et les secrets.
3. 33. Concevoir le workflow — Dessinez les nœuds, les transitions et l’état partagé. Prévoyez les chemins d’incertitude, d’erreur et de validation nécessaires au scénario.
4. 44. Implémenter progressivement — Commencez par le chemin nominal, vérifiez les sorties de chaque étape, puis ajoutez les branches de contrôle et une interface minimale si elle aide à la démonstration.
5. 55. Tester et documenter — Exécutez la checklist sur des cas normaux et limites, corrigez les défauts et expliquez comment reproduire les tests.
6. 66. Publier une démonstration propre — Présentez le dépôt, le schéma, les captures et les limites. Contrôlez les fichiers et l’historique avant de rendre le projet visible.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. Formation FormaGroup — Conception et orchestration d’agents d’intelligence artificielle formagroup.ma
2. FormaGroup — Technologie LangGraph formagroup.ma
3. JobInTech jobintech.academy
4. Formation intra-entreprise — OFPPT ofppt.ma