Créer un portfolio Amazon Bedrock au Maroc : un projet concret de A à Z

Choisir un projet adapté à son niveau

Un bon projet de portfolio Amazon Bedrock est assez petit pour être terminé, mais assez riche pour mettre en évidence plusieurs compétences. Il doit répondre à une question précise, s’appuyer sur des ressources que vous avez le droit d’utiliser et produire une démonstration compréhensible en quelques minutes. Un prototype cohérent et bien documenté est généralement plus convaincant qu’une application ambitieuse dont le fonctionnement reste opaque.

Pour un premier exercice, envisagez un assistant de questions-réponses sur un petit ensemble de documents publics : par exemple, des informations pratiques publiées par une administration ou un guide d’utilisation rédigé par vos soins. L’utilisateur pose une question ; l’application recherche des passages pertinents et demande au modèle de formuler une réponse appuyée sur ces éléments. L’idée est de montrer votre capacité à cadrer le besoin et à vérifier les réponses, pas de prétendre remplacer un service client ou un expert.

Adaptez le périmètre à votre expérience. Un profil débutant peut réaliser une démonstration simple avec un modèle accessible dans Bedrock, un prompt contrôlé et un jeu de questions préparé. Un profil plus avancé peut ajouter une recherche documentaire, une interface, des journaux de test, des contrôles d’accès ou une comparaison de réponses. Évitez d’ajouter des fonctions uniquement pour impressionner : chaque élément doit servir le besoin et pouvoir être expliqué.

• Le besoin tient en une phrase et concerne un utilisateur identifiable.
• Le prototype utilise peu de composants et reste testable de bout en bout.
• Les données sont publiques, synthétiques ou utilisées avec autorisation.
• Le résultat attendu peut être évalué avec des questions et des critères définis avant les essais.
• Le projet distingue clairement ce que le prototype fait, ce qu’il ne fait pas et ce qui resterait à construire.

Partir d’un besoin concret

Commencez par observer une tâche répétitive dans un métier ou une organisation : retrouver une consigne dans un document, résumer une procédure, orienter un usager vers la bonne rubrique ou préparer une première réponse à une question fréquente. Pour un portfolio, le problème n’a pas besoin de provenir d’une entreprise réelle. Vous pouvez le formuler comme un cas fictif, à condition de le signaler et de ne pas laisser entendre qu’un client a validé le produit.

Avant d’ouvrir la console AWS, décrivez le contexte, l’utilisateur et la difficulté. Définissez ce qui comptera comme une réussite : par exemple, répondre correctement à une série de questions couvertes par les documents, reconnaître les questions sans réponse et orienter l’utilisateur vers la source. Cette définition empêche de juger le prototype uniquement sur des réponses qui semblent fluides.

Un cas d’usage documentaire est adapté à un projet concret Amazon Bedrock parce qu’il permet de présenter la sélection des sources, la formulation des instructions, les essais et la gestion des réponses incertaines. Il n’est pas nécessaire de promettre une exactitude parfaite : expliquez comment vous avez limité les erreurs et ce qui doit rester sous la responsabilité d’une personne.

• Utilisateur : qui pose la question et dans quel contexte ?
• Besoin : quelle information cherche-t-il, et pourquoi est-elle difficile à trouver ?
• Périmètre : quels sujets le prototype couvre-t-il et lesquels sont exclus ?
• Réussite : quels critères observables permettent de juger une réponse ?
• Risque : que se passe-t-il si la réponse est incorrecte, incomplète ou hors sujet ?

Préparer les données, fichiers ou ressources

Réunissez d’abord un petit corpus clairement identifié : documents publics dont les conditions de réutilisation sont compatibles avec votre usage, ou contenus fictifs que vous avez créés. Gardez une trace de la provenance, de la date de collecte et des éventuelles conditions d’utilisation. Pour une démonstration, la qualité et la pertinence des documents comptent davantage que leur quantité.

N’utilisez pas les fichiers d’un employeur, d’un client ou d’un organisme de formation sans autorisation explicite. Retirez les noms, coordonnées, identifiants, données de santé, informations commerciales et autres éléments permettant d’identifier une personne ou une organisation. La pseudonymisation ne rend pas automatiquement une donnée publiable : si un cas réel est nécessaire, demandez l’accord approprié et faites valider le contenu avant toute diffusion.

Préparez aussi les ressources techniques : un compte AWS configuré, les autorisations nécessaires, un modèle disponible dans votre environnement, un emplacement de stockage adapté et une façon de tester l’application. Vérifiez les paramètres de région, d’accès et de conservation des journaux avant de traiter des contenus. Ne mettez jamais de clé, de secret, de jeton ou d’identifiant de compte dans le dépôt public, les captures d’écran ou le code de démonstration.

• Un dossier de documents de démonstration, sans données sensibles.
• Un inventaire des sources et des droits ou conditions d’utilisation connus.
• Une liste de questions représentatives, dont certaines hors périmètre.
• Des identifiants techniques protégés et jamais intégrés au dépôt public.
• Une note sur les paramètres AWS retenus et les ressources susceptibles d’occasionner des coûts.

Réaliser le projet par étapes

Commencez par écrire le brief et les critères de réussite. Ensuite, explorez le fonctionnement d’Amazon Bedrock dans votre environnement AWS et confirmez que vous pouvez utiliser le modèle choisi. Les modèles et fonctions proposés peuvent varier selon les disponibilités et la configuration du compte : vérifiez les options accessibles au moment où vous réalisez l’exercice, sans baser la démonstration sur une fonctionnalité que vous n’avez pas testée.

Construisez le prototype progressivement. Faites d’abord une interaction simple avec quelques questions fixes ; observez les réponses et corrigez les instructions. Si le besoin porte sur plusieurs documents, ajoutez une étape de recherche dans les sources et affichez les références utilisées lorsque votre conception le permet. Une interface minimale peut ensuite présenter la question, la réponse et, si possible, les éléments documentaires correspondants.

Enfin, préparez une démonstration qui suit un scénario stable : poser une question couverte, vérifier la source, puis poser une question à laquelle le corpus ne permet pas de répondre. Ce dernier cas révèle comment le système réagit à l’incertitude. Gardez le projet reproductible avec un README, des exemples et une procédure de lancement, sans publier de secrets ni de documents soumis à restriction.

• Définir le besoin, le public visé et les critères de réussite.
• Créer un jeu de données autorisé et une liste de questions de test.
• Configurer l’environnement Bedrock et vérifier les accès nécessaires.
• Construire une première interaction et examiner ses réponses.
• Ajouter uniquement les fonctions utiles : recherche documentaire, affichage des sources ou interface.
• Tester les cas normaux, les questions ambiguës et les demandes hors périmètre.
• Nettoyer le dépôt, rédiger la documentation et préparer une démonstration reproductible.

Tester, corriger et documenter

Les tests doivent porter sur le comportement, pas seulement sur le fait que l’application démarre. Préparez des questions dont vous connaissez la réponse à partir des documents ; ajoutez des formulations différentes, des questions qui combinent plusieurs informations et des demandes pour lesquelles aucune source ne répond. Comparez les résultats avec vos critères et notez les erreurs, les réponses partielles et les cas où le système aurait dû reconnaître son incertitude.

Contrôlez également la qualité des sources affichées, la cohérence entre une réponse et le document cité, la gestion des entrées inattendues et le comportement en cas d’erreur technique. Si vous mesurez la latence ou les coûts, présentez les conditions de mesure et évitez d’extrapoler à un usage massif à partir d’un petit test. Une démonstration de portfolio n’est pas, à elle seule, une preuve de performance en production.

• La réponse est-elle justifiée par le corpus, ou le système ajoute-t-il des éléments non étayés ?
• Le prototype sait-il signaler qu’il ne dispose pas d’information suffisante ?
• Les références affichées correspondent-elles réellement aux passages pertinents ?
• Le résultat reste-t-il raisonnable lorsque la question est ambiguë ou hors sujet ?
• Les erreurs de configuration ou de service sont-elles présentées sans exposer d’informations sensibles ?
• Le dépôt et les captures ne contiennent-ils ni secrets, ni données confidentielles, ni identifiants ?
• Un tiers peut-il comprendre les étapes suivies et reproduire le scénario de démonstration ?

Présenter son travail dans un portfolio

Présentez le projet sous forme d’étude de cas : le besoin, le public, le périmètre, les données utilisées, le schéma général, vos choix techniques, les essais effectués et les limites observées. Des captures d’écran sobres peuvent montrer l’interface, une réponse avec sa source et un cas où le système refuse de répondre faute d’information. Si vous publiez une vidéo, vérifiez chaque écran pour masquer les noms de comptes, les identifiants et les données non destinées au public.

Faites ressortir votre contribution personnelle. Si vous avez travaillé en groupe, précisez les tâches que vous avez réalisées et celles qui relèvent des autres participants. Ne présentez pas un prototype comme un produit déployé, une expérimentation comme un résultat validé par un client, ni un certificat de formation comme une certification officielle d’un éditeur.

La transparence renforce la valeur du portfolio. Indiquez que le système peut produire des réponses inexactes, que le contenu dépend des documents fournis et qu’une validation humaine peut être nécessaire. Expliquez aussi ce qui changerait avant une mise en production : revue de sécurité, tests plus larges, contrôle des accès, gestion des coûts, surveillance et validation par les personnes responsables du service.

• Une courte description du problème et de l’utilisateur visé.
• Un schéma simple des composants et du parcours d’une question.
• Des captures ou une vidéo avec des données fictives ou publiques.
• Un résumé des tests, des résultats observés et des limites.
• Un lien vers le code nettoyé, si sa publication est autorisée.
• Une mention explicite des éléments fictifs et de votre contribution personnelle.

Le parcours, étape par étape

1. 1Cadrer le besoin — Choisissez une tâche précise, identifiez l’utilisateur et définissez des critères de réussite vérifiables.
2. 2Préparer un corpus sûr — Utilisez des documents publics réutilisables ou synthétiques ; consignez leur provenance et excluez les contenus confidentiels.
3. 3Monter un prototype Bedrock — Vérifiez les modèles et accès disponibles dans votre environnement AWS, puis créez une interaction simple avant d’ajouter des fonctions.
4. 4Ajouter la recherche si elle sert le cas — Pour un assistant documentaire, reliez les questions aux passages pertinents et rendez les sources consultables lorsque possible.
5. 5Tester et corriger — Évaluez des questions couvertes, ambiguës et hors périmètre ; corrigez les réponses non étayées et les défauts observés.
6. 6Documenter et présenter — Préparez un README, une démonstration reproductible et une étude de cas honnête sur les choix, les résultats et les limites.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. FormaGroup — technologie Amazon Bedrock formagroup.ma
2. Amazon Web Services — Amazon Bedrock aws.amazon.com
3. AWS Skill Builder skillbuilder.aws
4. JobInTech jobintech.academy
5. OFPPT — Formation intra-entreprise ofppt.ma