Commencez ici

Un critère honnête avant de commencer. Si vous avez déjà appelé l’API Claude — ne serait-ce qu’une fois, même à partir d’un petit script de test — tout ce qui suit est de la révision pour vous, pas de la nouveauté. Passez au domaine 01 ; votre temps sera mieux employé sur les domaines qui rapportent des points.

Cette page s’adresse aux personnes qui n’ont connu l’IA qu’à travers une interface de chat, voire pas du tout, et qui visent maintenant la certification. Peut-être votre travail l’exige-t-il soudain. Peut-être vous demandez-vous si ce tournant de carrière est fait pour vous. Dans les deux cas : les huit guides qui suivent sont écrits pour un développeur qui construit avec l’API, et ils cessent d’expliquer les bases dès la première page. Les voici une fois pour toutes, pour qu’ils n’aient jamais à le faire.

01Qu’est-ce que Claude ?

Claude est une famille de modèles d’IA construits par Anthropic, une entreprise dont tout le métier est d’en construire. Cette phrase porte plus qu’elle ne le laisse voir, alors prenez-la en trois morceaux.

Un modèle, pas une application. Le nom Claude peut désigner trois portes d’accès au même modèle. Première porte : l’application et le site Claude — l’interface de chat où vous écrivez et où elle répond. Deuxième porte : Claude Code, un outil en ligne de commande qui modifie de véritables bases de code et utilise lui-même l’API. Troisième porte : l’API — le modèle brut, loué à la requête, sur lequel vous construisez vos propres produits. Le même moteur se cache derrière les trois portes. Cette certification porte sur la troisième porte — et tout le métier d’ingénieur IA avec elle.

Une famille, pas un modèle. La famille se décline en trois gammes entre lesquelles vous choisissez à chaque construction : Opus — la plus puissante, la plus lente et la plus chère ; Sonnet — le milieu équilibré, où vit la majorité du travail de production ; et Haiku — petite et rapide, conçue pour le volume. Chaque gamme porte un numéro de version (Opus 5.5, Sonnet 5, Haiku 4.5), et les numéros de version évoluent régulièrement — ils ont été vérifiés pour la dernière fois par rapport à la documentation d’Anthropic en septembre 2026. Revérifiez chaque chiffre par rapport à la documentation officielle avant de le mémoriser ; cette règle compte double sur cette page.

Un moteur de texte, pas un esprit. Derrière chaque porte, Claude est un programme entraîné sur d’immenses quantités de texte pour faire une seule chose extraordinairement bien : prédire le mot suivant, étant donné tout ce qui précède. (C’est une simplification délibérée — la version rigoureuse exigerait une carrière entière de mathématiques — mais c’est elle qui porte tout.) À une échelle suffisante, ce mécanisme permet de lire, d’écrire, de programmer et de produire ce qui ressemble à un raisonnement. Mais seul, le modèle n’a ni outils, ni mémoire d’un appel à l’autre, ni moyen d’agir. Il ne fait que répondre. Tout le reste — les outils, la mémoire, la boucle qui le fait travailler — est ce que vous construisez autour de lui. Ce n’est pas une limite qu’il faut excuser ; c’est la description du poste.

02Ce que fait un ingénieur IA au quotidien

Le titre est plus jeune que le métier. Un ingénieur IA construit des produits et des systèmes sur des modèles tout faits — des modèles comme Claude, entraînés par quelqu’un d’autre, loués à la requête. L’ingénieur qui entraîne ces modèles est un autre métier, ingénieur ML ou chercheur, et on confond les deux constamment. Cette certification porte résolument sur le premier.

Le travail, réduit à son squelette, est une boucle que vous répéterez mille fois :

• —Assembler le contexte. Décider de ce que le modèle voit lors de cette requête : les instructions, les données, les documents, les outils qu’il peut appeler. Cela — pas la formulation habile — est l’essentiel du métier.
• —Appeler le modèle. Envoyer ce contexte par l’API et recevoir une réponse, d’ordinaire en moins d’une seconde.
• —Inspecter ce qui revient. Le lire, ou mieux, laisser un contrôle le lire. Les modèles échouent avec assurance ; la boucle ne fonctionne que si les échecs sont détectés et signalés.
• —Mesurer et ajuster. Changer le contexte, le modèle ou les outils — et relancer.

Observez toutefois ce qui change. Un ingénieur backend encode les règles qui font le travail ; dans les fonctionnalités pilotées par modèle, vous spécifiez plus souvent les conditions sous lesquelles un modèle applique un jugement — le contexte qu’il voit, les outils qu’il peut appeler, les contrôles que sa sortie doit passer. Le code déterministe ne disparaît pas (l’orchestration, la validation et l’infrastructure restent à écrire), mais son centre de gravité passe de « voici les règles » à « voici les conditions ». C’est aussi pourquoi l’ingénierie de prompt est une facette du métier, pas le métier — un prompt est un levier, et le reste de la machine décide si le levier est relié à quelque chose. Choisir les modèles, concevoir les outils, structurer le contexte, mesurer si tout cela a fonctionné : voilà tout le champ du métier, et — commodément — la carte de cette certification.

03Votre premier appel d’API, sur le papier

Vous n’aurez rien à exécuter pour comprendre ce qui suit. Chaque appel de l’API Claude est la même courte conversation avec un étranger très rapide — quelqu’un qui vous oublie à l’instant où la réponse part.

Votre code envoie une requête : voici ma clé d’API qui prouve que j’ai le droit de demander ; utilise ce modèle ; et voici mes messages — un prompt système (les instructions permanentes qui disent au modèle quel est son travail) plus l’historique de la conversation. La réponse revient en données structurées : le texte que Claude a produit, le modèle qui a répondu, pourquoi il s’est arrêté, et — important — ce que cela a coûté.

Le coût se compte en tokens, et il vaut la peine de ralentir ici parce que tout le guide parle en tokens. Le modèle ne lit pas des mots ; il lit des tokens — des morceaux de texte d’environ un mot ou un fragment de mot. Vous payez les tokens que vous envoyez et les tokens qui reviennent, à des tarifs par million de tokens qui diffèrent entre l’entrée et la sortie, et selon le modèle.

Un exemple travaillé, aux chiffres ronds inventés pour ne jamais vieillir. Disons qu’un modèle facture 3 $ par million de tokens d’entrée et 15 $ par million de tokens de sortie. Une requête envoie 2 000 tokens et en reçoit 500 : cela fait 0,6 ¢ d’entrée plus 0,75 ¢ de sortie — environ 1,4 cent pour l’appel entier. Poussez cette arithmétique à un million de clients et vous voyez pourquoi « de combien de contexte cette fonctionnalité a-t-elle vraiment besoin ? » est une question d’entreprise, pas seulement technique. Pour une idée d’échelle : un paragraphe ordinaire se situe entre 100 et 200 tokens, donc une pleine page de texte en compte quelques milliers.

À chaque requête, le modèle ne peut voir qu’un nombre fini de tokens à la fois. Cette limite est la fenêtre de contexte — voyez-la comme l’espace disponible sur un bureau. Tout ce que Claude est susceptible d’utiliser lors de cette requête doit tenir sur le bureau en même temps : instructions, documents, historique de conversation, définitions d’outils, tout. Cet espace n’est pas gratuit non plus : plus de contexte coûte plus de tokens et, passé un certain point, dégrade la qualité des réponses. Gérer ce bureau est un domaine de certification à lui seul — vous le retrouverez au domaine 06.

Une dernière propriété façonne en silence tout ce guide : l’API est sans état. Le modèle ne retient rien entre les appels. Si vous voulez une conversation, c’est vous qui la maintenez — votre code renvoie tout l’historique à chaque requête, et la mémoire n’est que votre transcription qui grandit. Tout ce que vous lirez plus tard — sessions, prompt caching (la mise en cache des prompts), agents qui se souviennent — est une stratégie pour composer avec ce seul fait. (Et non, l’application de chat Claude n’y échappe pas : elle garde la transcription pour vous et la renvoie discrètement à chaque tour. Même moteur sans état ; quelqu’un d’autre fait le renvoi.)

04La carte du parcours

Tout ce qui précède constitue le socle du guide. Voici où chaque notion est développée en détail, et dans quel ordre les lire — les domaines les plus riches en points d’abord. Un avertissement avant de parcourir le tableau : il nommera des choses — sous-agents, fichiers de règles, évals, MCP — que cette page n’a pas expliquées. C’est délibéré. C’est une carte, pas un programme : on n’attend pas de vous que vous reconnaissiez le terrain, seulement que vous voyiez que chaque notion sera expliquée dans un domaine précis.

La certification, au fond, vous demande une seule chose : que vous compreniez ce qui arrive quand une requête quitte votre code, ce qu’en font les systèmes d’Anthropic, et tout ce qui peut mal tourner entre les deux. Vous savez maintenant assez pour que cette phrase soit un plan plutôt qu’un slogan. C’est avec le domaine 01 que commencent les contenus évalués.