Formation Claude Artifacts

Un artefact place un livrable dans une fenêtre dédiée, séparée de la conversation principale du chat. Cette interface permet de relire la version obtenue, de revenir en arrière et de demander des modifications sans repartir de zéro pendant la session. La personne garde le fil des échanges d'un côté et le livrable en cours de l'autre.

La création peut se déclencher automatiquement depuis le chat ou à la demande avec un prompt explicite. Selon le besoin, Claude prépare un document, du code, une visualisation, une page web ou un prototype interactif. Le mode de création Artifact dépend des capacités du compte ; Anthropic demande actuellement que l'exécution de code et la création de fichiers soient autorisées dans les réglages concernés.

Les actions visibles dépendent du type de contenu et du plan : copier, télécharger, diffuser, partager ou intégrer sur un site. Avant l'atelier, le participant vérifie donc l'interface réelle plutôt qu'une ancienne capture d'écran. Les fonctions sont contrôlées dans le centre d'aide Anthropic au moment de la session.

Anthropic nomme la bibliothèque Artifacts. Sa documentation anglaise écrit artifact en minuscule pour un livrable individuel ; la version française parle d'un artefact. Le pluriel artefacts désigne donc les créations, pas une seconde fonction.

Pendant la formation, Artifacts est conservé lorsqu'il désigne la rubrique de Claude. Cette page emploie parfois Artifact avec une majuscule dans ses intitulés pour rester cohérente avec la requête, sans le présenter comme un libellé officiel d'Anthropic. La traduction française sert dans les explications.

Dans Claude sur le web et l'application de bureau, la page Artifacts rassemble les créations ajoutées à la bibliothèque. Un artifact né dans une conversation n'y apparaît pas automatiquement : il faut l'ouvrir et utiliser l'action proposée par le compte. Les artefacts en cours restent liés à leur fil.

Sur la page Artifacts, le participant ouvre un artifact, puis compare sa version aux autres artefacts de la séance. Il sait ainsi quel libellé rechercher lorsqu'il reprend le travail après la formation.

Le travail commence par un objectif, un public et un livrable observable. En quinze minutes, le groupe rédige un plan simple : public visé, problème, entrées, sortie attendue et critères de recette. Ce cadrage évite de demander une application entière dans une phrase vague.

Dans Claude, le premier prompt décrit le contenu, le format, les contraintes et un exemple. Une version est générée puis testée immédiatement au cours de la session. Chaque retour porte sur un écart précis : libellé trop long, bouton absent, calcul faux, navigation confuse ou affichage mobile cassé. Une capture annotée rend les modifications plus rapides à comprendre.

Une seconde série de quinze minutes sert à comparer le livrable au plan. Le participant note ce qui fonctionne, ce qui reste manuel et ce qui exige un travail technique supplémentaire. Cette méthode transforme la création en petites étapes vérifiables, sans présenter le premier rendu comme un service terminé.

Une équipe marketing veut générer un mini-diagnostic sans développer un service complet. Dans Claude, le premier Artifact affiche trois questions et une sortie courte. Le prompt décrit le contenu attendu, les règles de calcul et le message d'erreur ; aucune donnée réelle n'est utilisée.

Un second Artifact propose une réponse différente au même besoin. Deux utilisateurs suivent le scénario pendant qu'un observateur note les hésitations et réalise une capture annotée. Chaque utilisateur doit comprendre l'interface sans consigne orale, puis expliquer quel outil lui a posé problème.

La maquette contient le libellé « Recevez la synthèse par e-mail », mais aucun email n'est envoyé. Ce projet sert à contrôler le consentement, le texte et la sortie avant toute connexion. Les deux artefacts restent des démonstrateurs. Même s'ils sont déjà des applications interactives dans Claude, ils ne deviennent pas des services de production sans une revue technique séparée.

Les artefacts de texte conviennent à une note, une procédure ou un support destiné à être repris. Un bloc de code sert à expliquer une logique ou préparer un composant. Une application web interactive convient à un calculateur, un questionnaire ou un tableau de suivi. Le format se choisit avant la production selon l'usage réel.

Pour des pages HTML ou un composant React, la recette couvre le clavier, le mobile, les contrastes, les erreurs et les états vides. Une fonction qui marche dans le panneau de prévisualisation peut échouer après export. Le composant et les outils de navigation doivent donc être relus et testés sur la surface destinée au public.

Le prototype reste distinct d'un service en production. Les dépendances, le stockage persistant, les droits, les performances et l'hébergement demandent une revue technique. Des Artifacts utiles peuvent devenir une spécification, une maquette interactive ou une base technique, mais ils ne remplacent pas cette revue.

Un test terrain ne demande pas une longue étude. Trois personnes exécutent la même tâche sans aide pendant que l'équipe relève les hésitations, les erreurs et le temps nécessaire. Le critère attendu est fixé avant le test : trouver un bouton, saisir une valeur ou terminer un parcours interactif.

Chaque session produit une liste courte de modifications classées par gravité. Le groupe corrige d'abord ce qui bloque, puis ce qui ralentit. Une nouvelle version est testée avec le même scénario. L'historique permet de revenir en arrière si une correction casse une fonctionnalité existante.

L'organisation conserve une fiche par artefact : propriétaire, public, état, dernière vérification et décision de publication. Cette fiche évite qu'un lien de démonstration soit présenté plusieurs mois plus tard comme une application maintenue.

Le stockage persistant permet à certaines créations de retrouver des informations entre deux sessions. Il peut être personnel, avec des entrées propres à chaque personne, ou partagé entre plusieurs membres. Un journal, un suivi d'habitudes et un tableau d'équipe n'ont pas le même mode de stockage.

Cette fonctionnalité est actuellement proposée sur les plans Pro, Max, Team et Enterprise, dans le navigateur et l'application de bureau. Les opérations de stockage ne fonctionnent qu'après publication ; elles échouent pendant le développement et les tests. La limite annoncée est de 20 Mo par artefact, pour des entrées textuelles uniquement ; ces valeurs sont revérifiées dans la documentation avant l'exercice.

Les données personnelles et partagées doivent rester séparées. Une mention explique à la personne ce que les autres peuvent voir. La dépublication supprime définitivement les deux formes de stockage, et le même artefact ne peut plus être publié ensuite : l'application doit prévoir son propre export ou l'équipe accepte explicitement cette perte avant d'agir.

MCP, le Model Context Protocol, permet à des artefacts interactifs créés dans Claude d'appeler des services externes autorisés. Une application peut par exemple lire une tâche dans Asana, consulter un calendrier ou préparer un message Slack. Le serveur MCP reste distinct de l'interface et impose ses propres droits.

Par défaut, chaque compte authentifie ses connecteurs MCP, même lorsque l'artefact a été partagé. Anthropic propose aussi en bêta une authentification gérée sur Team et Enterprise : l'administrateur peut fournir certains connecteurs à des groupes par le fournisseur d'identité. Cette exception ne l'autorise pas à choisir chaque outil appelé par chaque artefact.

L'atelier commence en lecture seule, avec un jeu de données factices. Les actions d'écriture sont ajoutées une par une, après validation. Un prompt contenu dans une source externe ne doit jamais obtenir plus de droits que le cadre défini par l'équipe. Chaque outil MCP reçoit uniquement le contexte nécessaire ; les autres outils restent hors périmètre.

Les comptes Free, Pro et Max peuvent publier des artefacts avec un lien public selon les fonctions disponibles. Les comptes Team et Enterprise utilisent un partage interne à l'organisation : les membres doivent être authentifiés. Un artefact créé dans un projet peut aussi exiger l'accès à cet espace. Chaque page publique est vérifiée avant diffusion.

Lors d'un partage interne Team ou Enterprise, les lecteurs autorisés accèdent aussi aux pièces jointes et aux fichiers de la conversation d'origine. Avant le partage, le propriétaire ouvre une conversation propre, retire les documents inutiles et vérifie le contenu des pièces restantes. Cette étape compte autant que la recette visuelle.

Après publication, un bouton peut fournir un extrait d'intégration pour afficher la page sur un site web. Les domaines autorisés sont définis dans l'interface Claude. Les règles de diffusion sont revérifiées dans la documentation officielle sur le partage avant la mise en ligne. L'équipe teste ensuite la page intégrée, car le comportement dans un site existant peut différer de la fenêtre Claude.

Le passage au produit commence par un inventaire : sources, dépendances, stockage, comptes, journalisation et support. Les éléments exportés sont placés dans un dépôt versionné. Claude Code peut aider aux modifications, mais la recette et la décision de mise en ligne restent humaines.

Une équipe peut garder les artefacts comme démonstrateurs, les partager en interne ou reprendre le code dans une application classique. Le bon choix dépend du nombre de personnes, des données traitées et du niveau de service attendu. Un usage ponctuel ne demande pas la même organisation qu'un produit utilisé chaque jour.

Le livrable final comprend le dossier de recette, les tests, les limites connues et la procédure de retrait. Ainsi, l'entreprise sait qui maintient l'application, où signaler une erreur et comment arrêter le service sans perdre les informations nécessaires.