Initiation à Claude code et à des prompts optimisés

Dans cette formation, je vous recommande Claude Code, mais les concepts seront les mêmes si vous optez pour un autre agent : Codex, Copilot…

Les agents deviennent de plus en plus puissants et chaque jour l’un d’entre-eux sort un nouveau modèle et dépasse les autres, jusqu’à jour suivant. Alors optez pour celui que vous préférez !

Pour ma part, je délègue aujourd’hui absolument tout à Claude (sauf l’écriture de mes cours). L’IA sait tout faire. Vous pourriez gérer une agence complètement autonome et composée uniquement d’agents IA.

Ce qui va bien sûr chambouler notre monde, non sans soulever quelques inquiétudes au passage.

Installer Claude en CLI ou Desktop

Commençons par installer Claude. Pour cela, on dispose de plusieurs approches dont :

• L’application Claude pour Windows, Mac, Linux…
• Ou alors l’invite de commande pour votre terminal.

La différence ? Dans l’application, vous avez tout-en-un, c’est bien présenté, visuellement travaillé.

Vous pouvez la télécharger gratuitement sur le site officiel :

Télécharger Claude

Et en ligne de commande, vous avez tout pareil mais en police monospace, et l’avantage principal c’est que vous pouvez l’utiliser sur n’importe quel logiciel de terminal.

Dans cet exemple, j’utilise Superset qui est très pratique car il permet d’ouvrir plusieurs fenêtres en même temps dans des onglets.

Pour installer Claude en ligne de commande (CLI), ouvrez un terminal et écrivez :

Vous pourriez également l’utiliser dans VS Code pour le coup. Mais je dois vous avouer un truc : je ne code plus, plus une seule ligne depuis des mois. Je laisse entièrement faire Claude. Car il est meilleur que nous, et de loin.

Pendant un moment, on a beaucoup entendu parler de Cursor, mais il reste utile uniquement si vous voulez facilement changer de fournisseur d’IA (entre Claude, Grok, Codex…). Cursor vous propose un forfait unique vous permettant de changer facilement.

Vraiment, ne négligez pas la puissance de l’IA : marketing, architecture logicielle, code, et même design. Elle fait tout mieux, et surtout beaucoup plus rapidement.

Comprendre cette dernière phrase en va de la survie de votre business ou votre agence.

Les concepts clés de Claude

Allez, on attaque avec Claude Code. Ouvrez le logiciel afin qu’on étudie les éléments qui se trouvent à l’écran.

Lorsqu’on ouvre Claude, on tombe sur le prompt classique destiné à lui poser des questions. C’est l’équivalent de ChatGPT en gros.

Mais nous, ce qui va nous intéresser, c’est de passer en mode Claude Code. Pour cela, cliquez sur le toggle en haut à droite de la sidebar :

La différence, c’est que Claude Code va être en mesure de travailler sur les fichiers de notre ordinateur, faire des commit, lancer des commandes terminal… C’est donc ce mode qui nous intéresse particulièrement.

Voici ce qui se trouve ensuite à l’écran :

Il y a 5 éléments qui vont attirer notre attention :

• En rose, le bouton pour lancer une nouvelle conversation avec un agent.
• En jaune, la liste des conversations en cours ou passées, rangées par projet.
• En vert, le choix du projet et de la branche git dans lesquels travailler.
• En bleu, le champ de conversation pour formuler votre prompt.
• En violet, le choix du modèle et de son effort.

On va maintenant voir cela plus en détails.

Ouvrir un projet et choisir la branche

On commence par ouvrir un projet. Pour cela, rendez-vous dans la zone en vert sur ma capture. Laissez « Local » sur la première étiquette : on va effectivement travailler depuis notre ordinateur.

Dans la seconde vignette, sélectionnez le dossier dans lequel on va travailler. Si c’est un nouveau projet, créez simplement un dossier vide sur votre ordinateur et ouvrez-le.

Cela peut-être un thème WordPress, une extension… D’ailleurs, ne versionnez jamais toute votre installation WordPress. Ce serait complètement contre-productif.

Ensuite, vous allez pouvoir choisir la branche sur laquelle travailler. Les branches git sont très pratiques pour travailler sur plusieurs fonctionnalités indépendamment.

Le principe de git, c’est de travailler une nouvelle fonctionnalité sur une branche séparée, et de fusionner cette branche avec la principale (on parle de merge) uniquement lorsqu’elle est prête à être mise en production.

Dans ces cas là, on demandera à Claude de faire une « Pull Request » qu’on ira ensuite valider sur GitHub (ou Gitlab selon ce que vous utilisez). Ensuite, la branche est fusionnée dans la branche principale qui détiendra désormais la somme du code des 2 branches.

D’ailleurs, si vous démarrez une nouvelle fonctionnalité, vous pouvez tout à fait partir de « Main » et demander à votre agent de créer une nouvelle branche.

Et enfin, il y a une petite case à cocher qui s’appelle « Worktree ». Et contre toute attente, elle va s’avérer essentielle !

Si vous lancez plusieurs agents en même temps sur des branches séparées pour ne pas créer de conflit, vous pensez que tout se passera bien, mais non !

En réalité, votre répertoire n’est capable d’avoir qu’une seule branche active à la fois. Donc si vous lancez 2 agents en même temps, chacun va changer de branche lorsqu’il va écrire du code. Et là, c’est l’embrouille.

Le Worktree permet de résoudre ce problème : Claude créé alors une copie du code provisoirement dans un sous-dossier, comme ça chaque agent aura son propre dossier de travail et sa propre branche.

Choix du modèle et de l’effort

Maintenant, on va choisir le modèle et l’effort (dans la zone violette de ma capture). C’est une décision importante car ça va influencer sur la dépense de vos tokens. Un modèle plus puissant, et un effort plus prononcé risquent de vous coûter votre forfait hebdomadaire beaucoup plus rapidement.

Les modèles évoluent régulièrement. À l’heure où je vous parle, le modèle par défaut est « Opus 5.5 » et il est très performant comme ça.

Petite anecdote : au moment de publier ce cours, j’avais écris Opus 5.4, mais Anthropic a annoncé quelques minutes plus tard l’arrivée de Opus 5.5. Quand je vous dit que ça va très vite…

Voici les modèles qui existent aujourd’hui :

• Haiku : rapide à répondre et économique, pour des tâches simples et à fort volume.
• Sonnet : équilibre entre rapidité, coût et capacité
• Opus : modèle très performant mais plus couteux, idéal pour le code
• Fable : le modèle le plus puissant, mais très couteux en token.

Ce dernier nécessite d’ailleurs un crédit hors forfait, et au vu de sa consommation, cela peut vous coûter plusieurs euros par minute.

Pour un petit projet, Sonnet pourrait suffire, mais je vous recommande de passer sur Opus. Un forfait à 16$ par mois pourra amplement suffire pour réaliser toutes vos tâches quotidiennes.

Maintenant, l’effort !

Ce paramètre permet de définir combien de tokens Claude va pouvoir dépenser en réfléchissant avant de vous répondre. Plus l’effort est haut, plus il va pouvoir aller creuser en profondeur et vous apporter une réponse de meilleure qualité.

Mais plus vous dépensez de tokens, plus votre forfait va fondre rapidement.

Par défaut, l’effort est configuré sur High, peu importe le modèle. C’est en général un bon compromis.

Mais si vous vous attaquez à une tâche très complexe, n’hésitez pas à le passer momentanément en Ultracode. Pensez à revenir sur High après coup.

Par exemple, j’avais du mal à trouver la cause d’un bug sur un projet client, et Claude aussi. Et pour cause, le bug était dû à 2 éléments totalement différents qui n’avaient aucun rapport entre-eux à priori. Le passage en Ultracode a permis à Claude d’analyser le code plus en profondeur, et de trouver enfin la source du problème.

Gérer les permissions

Autre sujet brulant : les permissions. Après tout, Claude va devoir créer des fichiers, dossiers, les modifier, les supprimer parfois, mais aussi lancer des scripts et des lignes de commande.

Donc pour éviter le drame, Claude va vous demander l’autorisation avant chaque action potentiellement critique. Ce qui est bien, mais très vite lassant.

Parce que lors d’un prompt, il va peut-être vous demander une autorisation 5 à 10 fois, si ce n’est plus. Et à un moment, on a envie qu’il soit plus autonome.

Alors quand vous vous sentirez plus à l’aise avec lui, vous pourrez sélectionner « Ignorer les permissions ». Ainsi, Claude sera totalement autonome.

Il existe aussi un mode « Plan », qui permet de planifier uniquement, sans toucher à une ligne de code. Mais aujourd’hui, peu importe le mode dans lequel vous êtes, vous pouvez simplement lui demander d’écrire un plan depuis votre prompt, et il comprendra qu’il ne doit pas toucher au code.

La fenêtre de contexte

Lorsque vous allez commencer à converser avec votre agent, vous allez remarquer une petite jauge circulaire en bas à droite qui va commencer à se teinter de bleu. C’est votre fenêtre de contexte.

En cliquant dessus, une fenêtre va apparaître avec plusieurs informations : messages, outils systèmes, outils MCP…

Tout ça indique l’occupation de la mémoire de votre agent. Dans la capture ci-dessus, on voit qu’elle atteint 34%, ce qui est correct.

Concrètement, le contexte est la mémoire de travail de l’agent. Il retient tout ce qui s’est dit depuis le début de la conversation. Et cette mémoire, comme la notre, a une limite.

Ce contexte va contenir l’historique de la conversation, le résultat des outils qu’il a lancé, le code source existant qu’il a pu lire, mais aussi des instructions qui viennent du système et qui cadrent son comportement.

Donc plus il a de contexte en tête, et mieux il fera son travail. Mais… plus ça vous coûtera en tokens, car à chaque nouveau prompt, l’IA va relire toute sa mémoire.

Bien prompter, c’est donc réussir à bien gérer le contexte : supprimer ce qui ne sert plus, repartir de 0 pour une nouvelle tâche, documenter l’important pour le garder dans le projet… Mais on en reparle juste après.

Forfaits, Tokens et consommation

Maintenant, parlons argent ! Actuellement les IA sont abordables, mais si on fait n’importe quoi, ça peut nous coûter cher.

Surtout qu’il y a une potentielle crise du token à venir, car Atnhropic, OpenAI et compagnie vous vendent des tokens pour une fraction du prix que ça leur coûte réellement. S’ils n’atteignent pas bientôt un seuil de rentabilité, ça risque de ne pas plaire aux investisseurs.

Si on va voir sur le site de Claude, on peut observer ces tarifs :

Un premier forfait à 15€ par mois vous permet d’obtenir assez de tokens pour vos tâches du quotidien. Comme j’alterne mes journées entre formations et code, ce forfait me suffit amplement.

Mais pour la plupart de mes collègues, ça ne suffisait pas, et ils ont dû basculer sur le forfait à 90€ par mois, voire même plus.

Maintenant, parlons des limites. Il en existe 2 :

• la limite hebdomadaire, qui se réinitialise une fois par semaine
• la limite des 5h : si vous consommez trop de token pendant cette période, il faudra attendre qu’elle se termine pour continuer votre travail.

Pour savoir où vous en êtes, cliquez sur la fenêtre de contexte, ou allez dans les réglages de l’app, dans la rubrique « Utilisation ».

Dans mon exemple, on voit que j’ai consommé 47% des tokens sur ma période de 5h. Il reste 1h58 avant la réinitialisation, donc je suis large !

Au niveau de la limite hebdomadaire, j’en suis à seulement 14% alors qu’on est mardi. Autant dire que je suis large !

On peut observer, en dessous, qu’il existe aussi des crédits d’utilisation supplémentaire. Si vous débordez de votre forfait seulement à de rares occasions, vous pourriez basculer sur les crédits, et vous constituer ainsi une réserve exceptionnelle de tokens.

C’est d’ailleurs dans ce crédit que puise Fable 5, car il n’est pas inclut dans le forfait initial. Mais attention : les crédits sont dépensés en usage réel, et se consomment beaucoup plus vite que dans le cadre du forfait.

Si vous créez une application en ligne qui fait appel à l’IA (imaginons un transcript de vidéo vers texte), ce sont ces crédits que vous consommerez également.

Bien prompter avec Claude

Maintenant, on va pouvoir prompter. Mais prompter, c’est tout un art. Et la maîtrise de cet art, c’est souvent ce qui va faire la différence encore une belle réalisation et une réalisation ratée.

Partez du principe que Claude sait absolument tout faire. Vraiment. Elle peut analyser, suggérer, décider de la meilleure architecture, coder, vérifier, optimiser, documenter… Bref, elle peut nous assister/remplacer sur l’intégralité de notre métier.

Et même si on ne va plus coder nous-même, cela ne veut pas dire qu’il ne faut pas acquérir de nouvelles compétences : plus on maîtrise un sujet, plus on sera en mesure de bien guider l’IA au travers des prompts. C’est cette différence entre un vibe codeur et un développeur.

Voyons maintenant quelques petites astuces pour bien réussir notre passage à l’IA :

Planifier une tâche complexe

Lorsqu’on se lance dans une tâche complexe, le plus efficace est de créer d’abord un plan. En demandant un plan à Claude, on s’assure qu’il ne va pas se jeter corps et âme dans le code.

À la place, il va créer un plan au format Markdown et vous le soumettre. Ainsi, vous allez pouvoir valider chaque étape avec lui, et demander des modifications ou des précisions si besoin.

Voici un exemple de prompt :

Là, Claude va comprendre qu’on va juste réaliser un plan. On lui indique aussi qu’il peut nous poser des questions. Il possède un outil interne qui s’appelle AskUserQuestions qui permet justement de nous préparer un petit formulaire.

Il nous proposera alors des choix multiples et recommandera à chaque fois une réponse :

Il le fera de lui même au moindre doute. Mais en l’écrivant, on s’assure qu’il n’assume pas des choses par manque d’information.

Dans la capture ci-dessus, Claude nous demande où placer la page d’options. Il propose alors d’ajouter un sous-menu dans « Réglages », ce qu’il recommande, ou créer un menu de premier niveau.

On peut alors choisir l’une des réponses proposées, ou si aucune ne nous plait, on peut saisir un nouveau prompt dans « Autre ».

En haut à gauche de la fenêtre de questions, on voit 2/4 : Claude a donc 4 questions à nous poser avant d’établir son plan.

Il m’a également demandé si on devait utiliser les composants natifs React de WordPress, ou une librairie custom et quel outil de build on va utiliser.

Au final, ces questions sont tout à fait légitimes et trahissent même le manque de précision de notre prompt : on aurait pu fournir ces informations lors du prompt initial.

Que cela nous serve de leçon : la prochaine fois, on réfléchira plus en détails à ce que l’on souhaite faire. Cela dit, Claude y a pensé pour nous.

Voici alors un prompt plus précis qu’on aurait pu donner :

Là, c’est beaucoup plus précis ! Mais au final, c’est tout à fait OK d’oublier des détails, et heureusement Claude y pensera de lui-même. Il possède une grande force de proposition mais aussi d’anticipation. Ce sont ces aspects qui évoluent au fur et à mesure des modèles et c’est plutôt bluffant.

Contextualiser et établir des règles dans le fichier Claude.md

Dans chaque projet, développeurs et agents vont se mettre d’accord sur une certaine direction à prendre : choix des technologies et frameworks, conventions de code, choses à faire et à ne pas faire, contexte et philosophie du projet…

Tout ça, on va l’écrire, de manière très succinte dans le fichier claude.md à la racine du projet. Et au lieu de l’écrire nous-même, on va demander à Claude de le faire.

Le fichier doit rester le plus léger possible, car il sera lu à chaque prompt. Donc si vous mettez 300 pages, vous allez dilapider vos tokens en un temps record.

Voici à quoi il pourrait ressembler :

On va donner une direction technique sur chaque technologie, chaque préférence de syntaxe afin que tout le monde soit au diapason, et que le code reste cohérent entre les fichiers.

Pour reprendre notre exemple de la section précédente : si on avait documenté qu’on imposait les technologies natives, Claude ne nous aurait pas posé la question sur la compilation et les composants.

Mais l’inverse est vrai : après qu’il a posé la question, on peut lui donner la nouvelle règle et lui demander de l’ajouter au ficher claude.md pour qu’il s’en souvienne. Après tout, ce fichier peut évoluer dans le temps.

Documenter

Lorsque le projet va grossir, le fichier claude.md ne va pas suffire. Il va falloir alors créer une documentation plus complète.

Et ça commence directement au début du projet : votre premier prompt ne devrait même pas être une instruction de code comme « Prépare la base d’une extension WordPress » mais plutôt une conversation sur l’idée que vous vous faites du projet.

Voyez-le (et promptez-le) comme une interview : décrivez votre projet, d’où vous vient l’idée, pourquoi vous croyez en ce projet, les ambitions futures, le business model…

Racontez-lui votre vie ! Tout cela le nourrira pour la suite, et ça permettra même de prendre des décisions plus éclairées à l’avenir.

Par exemple, les décisions prises ne seront pas les mêmes si votre projet est le projet principal de votre vie, ou si c’est juste un side project. Ça peut même tout changer sur les choix de priorités, d’architecture et de technologies.

Maintenant le but c’est de tout consigner dans le dossier /docs/ de votre projet :

• Chaque décision d’architecture suite à l’élaboration d’un plan ;
• Chaque fonctionnalité terminée ;
• Chaque bug corrigé ;

Tout peut être, et doit être documenté pour le futur. La documentation a toujours été importante dans un projet, mais par manque de temps, on l’a souvent négligée.

Laissez Claude organiser la documentation comme il le souhaite. Il écrira des fichiers .md dans divers sous-dossiers et en général c’est plutôt propre. d’ailleurs il mettra souvent un fichier readme.md à la racine, qui servira de sommaire à la documentation.

Ainsi, Claude n’aura pas besoin de tout lire à chaque fois, et cela évitera de saturer le contexte pour rien.

D’ailleurs, plus tard, lorsqu’une modification de code impliquera un concept documenté, vous verrez Claude vous indiquera qu’il met à jour également la documentation. Et s’il oublie, n’hésitez pas à le lui rappeler.

Les skills : le super pouvoir des agents IA

L’un des meilleurs concepts de l’IA, c’est de pouvoir créer et lancer des skills. Voyez le skill comme une procédure pas à pas à suivre. Un mode d’emploi, en quelques sortes.

Voici quelques idées de skills WordPress qu’on explorera dans les prochains cours :

• Automatiser l’installation de WordPress en local, sans logiciel autre que Docker ;
• Créer une check-list de vérification automatisée, pour valider qu’un site est prêt à être en ligne (SEO, RGPD, plugins configurés, sécurité en place…) ;
• Automatiser la mise en production grâce à de la CI/CD et des actions github ;
• Coder une nouvelle fonctionnalité à partir d’une tâche Monday, et créer une Pull Request sur Github. Automatiser tout le pipeline de production en somme.

Si vous avez en stock un skill de sécurité, vous pouvez le lancer simplement en écrivant /security dans votre prompt, sans forcément être au début du prompt :

D’ailleurs, Claude pourra prendre l’initiative d’en lancer automatiquement s’il juge que c’est judicieux. Dans le prompt ci-dessus, il l’aurait probablement lancé même si je n’avais saisi que le début de la phrase.

Bon à savoir : les skills ne sont pas lus en intégralité à chaque prompt. Et heureusement, sinon ciao les tokens. À la place, l’agent lit simplement la description au début du fichier.

Il existe des skills internes, des skills que vous pouvez télécharger, et bien entendu des skills que vous allez pouvoir créer vous-même. Ce sont ces derniers qui seront les plus intéressants.

D’ailleurs, tentez de lancer le skill /usage dans Claude Code : cela vous affiche votre consommation actuelle par rapport à la limite des 5h et hebdomadaire !

Sur Internet, il existe le site skills.sh qui est une véritable mine d’or pour des skills, rangés par technologie. On en trouve pour WordPress, pour JavaScript, le design…

Matt Pocock, ancien de chez Vercel et développeur JS, a créé un bon nombre de skills super intéressants pour vos projets. N’hésitez pas à jeter un œil.

Créer un skill

Maintenant, on va pouvoir créer des skills sur mesure qui répondront complètement à nos besoins. C’est encore là qu’on sera les plus efficaces.

D’ailleurs, il existe un skill pour vous aider à créer des skills. C’est le /skill-creator, intégré nativement dans Claude Code.

Vous en avez marre de prompter pour créer des pages d’options : faites un skill. Marre de prompter pour rédiger un article : faites un skill. Marre de vous relire pour améliorer vos contenus : faites un skill. Bref, vous m’avez compris : faites des skills.

Dans un skill on va avoir des séries d’instructions et de bonnes pratiques à suivre. Le but est de conditionner l’IA à faire les choses de manières précises. On parle souvent de « Harness Engineering ».

Voyez l’IA comme un cheval qui peut partir où bon lui semble. Mais dès qu’on lui met un harnais, on reprend le contrôle de la direction.

Les skills sont de simples fichiers .md (comme la doc) et seront stockés cette fois dans le dossier .claude/skills.

Voici un exemple issu de l’un de mes projets :

Ce skill me sert à mettre en production sur wordpress.org l’un de mes plugins. On peut observer plusieurs choses :

• Au début, je demande à Claude de vérifier le numéro de version actuel de mon extension.
• Ensuite, il doit définir le nouveau numéro de version : mineure si les modifications sont légères, majeure s’il y a de grosses nouveautés.
• Il va alors me demander confirmation en me posant la question et en me proposant une recommandation.
• Puis, il va mettre à jour les numéros de version dans les fichiers correspondants à 3 endroits). C’est un vrai plaisir de ne plus avoir à le faire à la main.
• Ensuite, il épluche mes derniers commits Git afin de me suggérer ce qu’il faut ajouter au changelog du readme.txt. Là encore, je confirme.
• Enfin, il commit, push, et publie un tag, ce qui va lancer la ci/cd côté GitHub.

En résumé, lorsque je veux mettre en ligne une nouvelle version de mon extension, j’ai qu’une chose à faire : lancer /release. Et franchement, c’est magique.

Economiser ses tokens

Et pour terminer, on va voir comment prompter sans se ruiner. Les tokens c’est le nouveau nerf de la guerre. C’est un mélange de bon sens et de ce qu’on a déjà vu dans ce cours :

Soyez précis sur votre prompt

Plus votre prompt est précis, moins l’IA a besoin de deviner ou chercher (dans le code, sur le web…).

Vous pouvez faire référence à un fichier, un dossier ou une documentation grâce à la commande @ suivi du nom du fichier.

Cela permettra à votre agent de savoir où chercher. C’est notamment utile si votre codebase commence à être conséquente.

Choisissez le bon modèle et le bon effort

Comme on l’a vu, les modèles plus récents sont les plus couteux en tokens. Pareil pour l’effort. Mais pour des tâches simples, vous n’avez pas besoin de sortir la ferrari. Adaptez votre modèle à votre demande.

Lancez une nouvelle conversation

Lorsque vous en avez fini avec un sujet, n’hésitez pas à relancer une conversation pour partir d’un contexte tout neuf. Comme on l’a vu, plus le contexte est chargé, plus la consommation de tokens va se faire sentir.

Aidez votre agent avec une architecture propre

Si votre code est en bordel, ça ne va pas aider votre agent à s’y retrouver. Demandez-lui alors de ranger le code en respectant les bonnes pratiques, comme le DDD : Domain Driven Development.

Pour faire simple : chaque fonctionnalité majeure aura son propre dossier. Pour un site e-commerce, ça veut dire qu’il y aura un dossier checkout, cart, catalog, orders…

De temps à autres, prenez le temps de lancer une refactorisation pour optimiser le code existant. L’IA a tendance à empiler du code par moment, et une fois que vous avez assez de recul, c’est le bon moment pour faire un point et réorganiser un peu tout ça.

Optimiser les coûts avec RTK

Il existe un outil nommé RTK qui remplace les commandes de base du terminal afin de réduire le texte affiché en sortie. Moins de texte = moins de tokens consommés lors de la lecture par l’agent.

En écrivant la commande rtk gain dans votre terminal, vous pourrez voir, pour chaque projet, le gain effectif en terme de token sur les différentes commandes de terminal.

En fait, votre agent va souvent lancer des commandes dans le terminal pour analyser votre code. La commande diff par exemple permet de comparer le contenu de 2 fichiers.

Dans cet exemple, on peut voir que la commande a été lancée 20 fois et que près de 50 000 tokens on été économisés.

Rendre votre agent moins bavard

Enfin, certains se plaignent que leur agent est beaucoup trop bavard, et fournit beaucoup trop d’informations inutiles. Ce qui consomme d’ailleurs des tokens.

Si jamais vous voulez lui « couper la chique », vous pouvez installer Caveman qui va forcer votre agent à abréger.

Voici un exemple :

Résultats plus lisibles, tokens économisés !

Aller plus loin avec Claude

Si ce cours vous a donné envie d’aller plus loin avec Claude et Claude Code, n’hésitez pas à consulter les cours gratuits officiels directement sur le site de Claude :

Claude Academy

Des centaines de cours et de webinaires sont disponibles pour tout savoir à propos de Claude, Cowork, Code…

L’IA évolue rapidement, alors n’hésitez pas à suivre le compte X d’Anthropic pour être tenu au courant des nouvelles fonctionnalités et nouveaux modèles disponibles.

---

Et voilà, vous êtes prêt à prompter comme jamais avec Claude. Dans les prochains cours, on va voir comment se connecter à notre site pour que notre agent puisse effectuer toute sorte de tâches comme installer une extension, créer du contenu, modifier les configurations…

Et ensuite, on va créer nos propres skills pour automatiser l’installation de WordPress et son déploiement vers son serveur de production. Une CI/CD comme vous n’avez jamais osé en rêver.