Portfolio Anthropic Claude API au Maroc : concevoir un projet concret, étape par étape

Choisir un projet adapté à son niveau

Un portfolio Anthropic Claude API doit montrer un raisonnement que l’on peut comprendre et vérifier. Un projet trop vaste — par exemple un assistant qui prétend traiter tous les besoins d’une entreprise — rend difficile l’explication des choix et multiplie les risques de défauts. À l’inverse, un petit outil bien délimité permet de présenter clairement le problème, les entrées, les réponses attendues et les limites.

Pour un projet Anthropic Claude API débutant, privilégiez une fonction principale : résumer un document, classer des demandes, rédiger un brouillon à partir d’informations fournies ou répondre à des questions limitées à un petit corpus. Un assistant de consultation de documents est un bon choix, car il met en évidence les étapes essentielles : préparer les ressources, transmettre une requête à l’API, afficher le résultat et vérifier qu’il reste lié aux éléments disponibles.

Définissez le périmètre avant de coder. Par exemple : « L’application aide un utilisateur à retrouver des informations dans un mini-guide fictif de procédures, et indique lorsqu’elle ne trouve pas de réponse suffisante. » Cette formulation est plus utile qu’une promesse vague d’« assistant intelligent ». Elle indique ce qui entre dans le système, ce qu’il doit produire et ce qu’il ne doit pas prétendre faire.

Choisissez une difficulté compatible avec vos compétences. Si vous débutez en développement, une interface simple et un petit ensemble de documents suffisent. Si vous avez déjà de l’expérience, ajoutez une séparation entre interface et serveur, une journalisation sans données sensibles, une gestion des erreurs et une suite de tests. N’ajoutez pas une architecture complexe uniquement pour impressionner : chaque composant présenté doit avoir une raison d’être.

• Projet faisable : une fonction principale, des entrées bien définies et un résultat démontrable.
• Projet utile : un problème compréhensible par une entreprise, une association ou un métier précis.
• Projet évaluable : des exemples permettant de vérifier si la réponse est correcte, incomplète ou hors périmètre.
• Projet honnête : des limites explicites, notamment le risque de réponse erronée ou insuffisamment étayée.

Partir d’un besoin concret

Repérez une tâche répétitive et circonscrite. Dans un service client, il peut s’agir de retrouver une procédure dans un guide interne fictif. Pour une petite structure, le besoin peut être de transformer une demande en brouillon de réponse, sans envoyer automatiquement le message. Pour une équipe administrative, on peut imaginer une extraction de champs à partir de formulaires d’exemple. Ces scénarios sont des pistes de projet, pas des promesses d’automatisation complète.

Avant de choisir, décrivez l’utilisateur, sa tâche actuelle et le point de friction. Demandez-vous ce qui constitue une bonne réponse : réponse exacte, résumé fidèle, ton adapté ou renvoi vers un passage du document. Prévoyez aussi les cas où l’application doit s’abstenir : document absent, question ambiguë, informations contradictoires ou demande portant sur un sujet que le système ne couvre pas.

Un exercice pratique Anthropic Claude API peut être présenté sous forme de brief, comme dans un petit projet client. Le brief ci-dessous est volontairement limité : il permet de montrer l’intégration de l’API et les contrôles sans prétendre que le modèle remplace un professionnel.

• Objectif : créer un assistant de consultation d’un mini-guide fictif de procédures.
• Utilisateur cible : une personne qui veut retrouver rapidement une consigne dans ce guide.
• Entrées : une question rédigée par l’utilisateur et un ensemble restreint de textes de démonstration.
• Comportement attendu : fournir une réponse concise, indiquer les éléments qui l’étayent et signaler quand le contenu disponible ne suffit pas.
• Livrables : application démontrable, code source sans secret, exemples de tests, fiche de démarrage, note sur les limites et captures d’écran.
• Hors périmètre : conseil professionnel, décision automatique, traitement de données réelles confidentielles et garantie que toute réponse du modèle est exacte.

Préparer les données, fichiers ou ressources

La qualité du résultat dépend aussi des ressources utilisées. Pour un projet de démonstration, rédigez vous-même quelques documents fictifs ou choisissez des contenus dont la réutilisation est autorisée. Gardez une trace de leur provenance et des conditions d’utilisation. Même si un document est accessible en ligne, cela ne signifie pas automatiquement qu’il peut être recopié, redistribué ou intégré à une démonstration publique.

Évitez les informations personnelles et les documents internes : dossiers clients, contrats, courriels, procédures non publiques ou fichiers récupérés dans un contexte professionnel. N’utilisez pas les données d’un employeur ou d’un client sans autorisation explicite. Si vous avez besoin de tester des formats réalistes, créez des exemples synthétiques et remplacez les noms, adresses et identifiants par des valeurs fictives.

Préparez également l’accès technique. Créez et stockez la clé API dans un mécanisme prévu pour les secrets côté serveur, par exemple une variable d’environnement locale non versionnée. Ne l’intégrez pas dans le code d’une page web, une capture d’écran, un dépôt public ou un fichier de configuration partagé. Dans le portfolio, montrez comment configurer la variable sans en révéler la valeur.

Enfin, définissez quelques questions de test avant d’écrire les consignes destinées au modèle. Incluez une question dont la réponse figure clairement dans les ressources, une question à réponse partielle, une question sans réponse dans les documents et une demande ambiguë. Ces cas aideront à mesurer le comportement réel du projet, plutôt qu’à sélectionner seulement les exemples où il fonctionne bien.

• Inventaire des fichiers et de leur provenance.
• Vérification des droits d’utilisation et absence de données confidentielles.
• Exemples synthétiques pour les démonstrations et les tests.
• Clé API conservée côté serveur, exclue du dépôt et masquée dans les captures.
• Jeu de questions de test défini avant les ajustements.

Réaliser le projet par étapes

Commencez par un parcours utilisateur dessiné en quelques lignes : l’utilisateur saisit une question, l’application vérifie qu’elle est exploitable, le serveur prépare la requête, l’API renvoie une réponse et l’interface affiche le résultat avec une indication sur les sources consultées. Ce schéma permet de séparer ce que fait votre code de ce que produit le modèle.

Construisez ensuite une version minimale avant d’ajouter des options. Dans une première étape, vérifiez que le serveur peut appeler l’Anthropic Claude API avec une requête simple et traiter une réponse. Gérez les erreurs attendues : absence de clé, problème de connexion, réponse invalide ou requête qui échoue. Ne faites pas apparaître dans l’interface les détails techniques sensibles.

Ajoutez les documents et la logique de consultation de façon progressive. Pour une petite démonstration, il peut suffire de sélectionner les passages pertinents dans un corpus réduit, puis de les transmettre avec la question. Si vous choisissez une approche plus avancée, expliquez-la dans la documentation et ne la présentez pas comme nécessaire à tous les projets. Dans les deux cas, l’assistant doit être encouragé à reconnaître que les ressources ne permettent pas de répondre plutôt qu’à inventer une information.

Rédigez et ajustez les consignes du modèle à partir des tests. Donnez-lui un rôle limité, précisez les documents qu’il peut utiliser, demandez une réponse lisible et définissez la conduite à tenir en cas d’incertitude. Une consigne ne garantit pas à elle seule la fiabilité : elle doit être évaluée sur des exemples variés.

Terminez par l’expérience utilisateur. Indiquez que le résultat est généré par un modèle et peut nécessiter une vérification. Rendez visibles les erreurs compréhensibles, évitez les boutons qui promettent une action réellement absente et distinguez les réponses appuyées par les documents des commentaires générés. Gardez la validation humaine si le résultat pourrait influencer une décision importante.

• 1. Définir le périmètre, l’utilisateur cible et les critères de réussite.
• 2. Préparer un petit corpus fictif ou réutilisable et un jeu de questions représentatives.
• 3. Créer une interface minimale et un serveur qui protège la clé API.
• 4. Réaliser un premier appel à l’API et traiter les réponses comme les erreurs.
• 5. Ajouter le contexte documentaire et des consignes limitées au cas d’usage.
• 6. Tester les cas normaux, ambigus, incomplets et hors périmètre.
• 7. Améliorer l’interface, documenter les choix puis préparer une démonstration reproductible.

Tester, corriger et documenter

Une démonstration réussie n’est pas une preuve suffisante de qualité. Testez plusieurs formulations d’une même question et vérifiez si l’application reste utile quand le contexte change. Notez les erreurs observées et les corrections apportées. Pour un portfolio, cette démarche est souvent plus convaincante qu’une longue liste de fonctionnalités, car elle montre comment vous évaluez le comportement d’un système fondé sur un modèle.

Documentez les décisions de conception : pourquoi le besoin a été choisi, comment les ressources sont préparées, quelles informations sont envoyées à l’API et comment l’application gère l’absence de réponse. Précisez ce qui est fait par votre code et ce qui dépend du modèle. Si vous avez ajouté une fonctionnalité non testée, indiquez-le clairement plutôt que de la présenter comme fiable.

Un dépôt public peut contenir le code, un exemple de configuration sans valeur secrète, les étapes d’installation et des données de démonstration autorisées. Il ne doit pas contenir la clé API, des journaux avec des données personnelles, des documents d’entreprise ou des captures montrant des informations réelles. Relisez aussi l’historique du dépôt : retirer un secret du fichier courant ne garantit pas qu’il a disparu des versions précédentes.

• Checklist de contrôle qualité :
• Le cas d’usage est-il expliqué en une phrase, avec un périmètre et des limites clairs ?
• Les fichiers utilisés sont-ils fictifs, publics avec réutilisation autorisée, ou explicitement autorisés ?
• La clé API est-elle absente du code livré, des captures, de l’historique public et des journaux ?
• L’application traite-t-elle une question répondable, une question ambiguë, une question sans réponse et une entrée vide ?
• La réponse reste-t-elle liée aux éléments fournis, et l’incertitude est-elle visible ?
• Les erreurs techniques sont-elles gérées sans exposer de secret ni de détail inutile ?
• La démonstration a-t-elle été rejouée à partir des instructions de démarrage ?
• Les captures et exemples sont-ils exempts de données personnelles ou confidentielles ?
• Les limites et les points restant à améliorer sont-ils décrits honnêtement ?

Présenter son travail dans un portfolio

Organisez la présentation pour qu’un recruteur ou un client comprenne rapidement le projet. Commencez par le besoin et l’utilisateur, puis montrez le parcours, les choix techniques et un exemple de résultat. Une courte démonstration peut faire apparaître une question traitée correctement, puis une question hors corpus où l’application sait signaler ses limites. Ne sélectionnez pas uniquement les sorties les plus flatteuses.

Ajoutez des captures d’écran lisibles et expurgées de tout secret. Si vous enregistrez une vidéo, utilisez un environnement de démonstration et des données fictives. Accompagnez les images d’une légende qui précise l’entrée, le résultat attendu et ce que l’exemple permet réellement d’observer. Le dépôt ou la fiche du projet doit également indiquer les prérequis, la configuration sans secret, les étapes de lancement et les tests disponibles.

Présentez votre contribution avec précision. Si vous avez utilisé une bibliothèque, un modèle ou un exemple externe, mentionnez son rôle. Distinguez les éléments effectivement construits des idées envisagées. Si l’application ne mesure pas la justesse de manière exhaustive, dites-le. Cette transparence aide le lecteur à évaluer votre travail sans lui faire croire que le prototype est prêt pour un usage sensible.

Pour chercher un poste ou une mission au Maroc, reliez enfin le projet à une situation professionnelle concrète : recherche d’information, préparation de brouillons, classement ou aide à la consultation de ressources. Expliquez ce qu’il faudrait valider avant un déploiement réel, notamment les droits sur les données, la sécurité, la qualité des réponses et la supervision humaine. Votre projet devient alors une preuve de démarche, et non une promesse de remplacement d’un processus complet.

• Une phrase de présentation et un brief synthétique.
• Une démonstration courte avec des données non sensibles.
• Des captures légendées et une explication des résultats observés.
• Un dépôt documenté, sans secrets ni ressources protégées.
• Une section « limites et améliorations possibles » fondée sur les tests réalisés.

Le parcours, étape par étape

1. 1Cibler un besoin démontrable — Choisissez un utilisateur et une tâche précise, puis formulez l’objectif, le résultat attendu et les cas où l’assistant doit reconnaître ses limites.
2. 2Préparer un environnement sûr — Réunissez des ressources fictives ou autorisées, créez des questions de test et configurez la clé API côté serveur, sans la publier.
3. 3Construire une version minimale — Réalisez l’interface et le serveur, effectuez un appel à l’Anthropic Claude API et gérez les erreurs courantes avant d’ajouter des fonctions.
4. 4Intégrer le contexte et les consignes — Fournissez uniquement les éléments utiles au cas d’usage, demandez une réponse limitée à ces ressources et prévoyez une sortie en cas d’incertitude.
5. 5Tester et corriger — Évaluez les réponses avec des cas variés, relevez les défauts, ajustez le projet et conservez une trace des limites qui persistent.
6. 6Documenter et présenter — Préparez les instructions de lancement, les captures expurgées, une démonstration reproductible et une explication honnête de votre contribution.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. JobInTech jobintech.academy
2. Formation intra-entreprise — OFPPT ofppt.ma
3. FormaGroup — Anthropic Claude API formagroup.ma
4. FormaGroup — Guide projet portfolio Anthropic Claude API au Maroc formagroup.ma