Applications et intégration

Si vous n’étudiez qu’un domaine à fond, que ce soit celui-ci. Applications et intégration représente à lui seul un tiers de l’examen. C’est aussi le domaine auquel le cours Academy recommandé (Building with the Claude API) correspond le plus directement — vos heures d’étude et les points s’alignent ici mieux que partout ailleurs. Et c’est là que vivent les questions de scénario : face à cette exigence, quelle architecture ? Quel modèle ? Quel endpoint ?

Une carte avant de partir. L’examen nomme six sous-domaines ; cette page compte plus de six sections, et c’est voulu. Les sections 01–04 suivent une à une les quatre premiers sous-domaines. La section 05 couvre ensemble les deux sous-domaines de configuration — leur analyse détaillée vit sur la page du domaine Claude Code. La section 06 est un aparté d’intégration que l’examen affectionne. Tout ce qui suit — les tableaux de révision, les pièges, le quiz — est de l’aide à la révision, pas un nouveau programme. Et une légende pour le balisage : la prose explique, les encadrés « À retenir pour l’examen » portent les faits dont les questions sont faites, et les pièges sont les mauvaises réponses déguisées en bonnes.

01De l’exigence à l’architecture

Le fil conducteur du premier sous-domaine est la retenue. Il part d’une distinction que l’examen cite presque mot pour mot : une exigence métier énonce ce que l’organisation veut — répondre plus vite aux questions des clients, relire chaque pull request. Une exigence fonctionnelle énonce ce que le système doit faire pour y répondre. Convertir l’une en l’autre, c’est votre travail.

Ensuite, choisissez l’architecture la moins complexe qui satisfait l’exigence fonctionnelle : un appel de modèle, ou une chaîne fixe, ou un agent — dans cet ordre de coût croissant. Les agents échangent de la latence et de l’argent contre de la performance sur la tâche, raison pour laquelle un objectif de temps de réponse ou un plafond de dépense fait partie de l’exigence elle-même, plutôt qu’un détail boulonné après coup.

Le choix du modèle tourne sur trois questions : de quelles capacités la tâche a-t-elle réellement besoin, à quelle vitesse les réponses doivent-elles arriver, et que permet le budget entre développement et production ?

Voici la forme de question que l’examen aime. Un travail nocturne traite des millions d’enregistrements. Personne n’a besoin des résultats avant le matin, et le coût est la priorité. La réponse est l’API Message Batches — asynchrone, et à la moitié du prix des appels synchrones. Le streaming est le leurre de cette question : il améliore la latence perçue, pas le coût ni le débit.

Puis la discipline qui ferme la boucle : une exigence n’est pas terminée tant qu’elle n’a pas une évaluation testable avec un seuil de réussite. Des évals construites à partir de vos vrais prompts et de vos vraies données sont la manière de vérifier les choix de modèle autrement qu’au ressenti — un thème sur lequel cet examen revient d’un domaine à l’autre.

02Cycles de vie des modèles et versions de l’API

Chaque modèle Claude traverse quatre états. Active signifie pleinement pris en charge — la recommandation. Legacy signifie que le modèle n’est plus mis à jour — candidat à une dépréciation future. Deprecated signifie qu’un remplacement et une date de retrait ont été nommés. Retired signifie disparu ; les requêtes échouent.

Ce que les gens ratent se situe entre les deux derniers : deprecated ne veut pas dire cassé. Le modèle répond toujours, et rien dans vos appels ne change encore. Seule la date de retrait est une vraie échéance — et cette distinction est un grand classique de l’examen.

Les engagements d’Anthropic ici sont concrets : un minimum de 60 jours de préavis avant le retrait d’un modèle publiquement disponible, un e-mail aux clients concernés, la documentation de chaque dépréciation. Quand un avis arrive, la réponse recommandée est mesurée, pas dramatique. Vérifiez quelles clés appellent encore l’ancien modèle — la page Usage de la Console exporte un CSV ventilé par clé API et par modèle. Testez le remplacement bien avant l’échéance. Puis migrez délibérément : pas dans la panique le premier jour, et pas après que les erreurs ont commencé.

Deux frontières que l’examen sonde. D’abord, le calendrier de dépréciation d’Anthropic ne couvre que les plateformes opérées par Anthropic — l’API Claude et ses variantes hébergées dans le cloud. Amazon Bedrock et Google Cloud Vertex tiennent leurs propres calendriers de retrait pour les mêmes modèles ; un plan de migration peut nécessiter des dates différentes selon la plateforme.

Ensuite, la promesse de versionnage : au sein d’une même version de l’API, Anthropic ne casse pas les entrées et sorties existantes — mais peut ajouter des champs de requête optionnels, de nouvelles valeurs de sortie et de nouvelles variantes de valeurs proches d’énumérations, y compris de nouveaux types d’événements de streaming. Un client qui lève une exception sur un type d’événement qu’il ne reconnaît pas est un défaut qui attend la prochaine version. Gérez proprement les valeurs inconnues.

03L’API Messages en profondeur

Un fait sur lequel tout le reste ici repose : l’API Messages est sans état. Le serveur ne stocke rien entre les appels. Chaque requête transporte la conversation complète — chaque tour, chaque image, le prompt système — et gérer, rogner et faire persister cet historique est le travail de votre application.

L’absence d’état autorise aussi un tour de passe-passe : les tours d’assistant dans l’historique n’ont pas besoin d’être des propos que Claude a réellement tenus. Les messages d’assistant synthétiques sont parfaitement valides, et c’est ainsi que fonctionnent le prefill et le dialogue en few-shot.

Une requête a trois parties essentielles : le modèle, un plafond max_tokens, et la liste messages de tours rôle-plus-contenu. La réponse vous rend plus que du texte. Son champ content est un tableau de blocs typés — text, tool_use, thinking — et le champ stop_reason vous dit pourquoi la génération s’est arrêtée.

Les instructions persistantes vivent dans le paramètre system de premier niveau — c’est le champ role : qui Claude est en train d’être. Sur plusieurs modèles actuels, vous pouvez aussi envoyer un message de rôle system en milieu de conversation, après un tour utilisateur ; il porte la même autorité, mais il ne peut pas être le premier message.

Le prefill est l’autre geste puissant. Placez un message d’assistant en dernière position, et le modèle le traite comme le début de sa propre réponse, puis continue à partir de là. Terminez un tour par « The answer is ( » avec max_tokens réglé à 1, et vous recevrez un unique token en retour — arrêté par max_tokens, exactement comme prévu.

La vision arrive en blocs d’image à l’intérieur des tours utilisateur — JPEG, PNG, GIF et WebP. Plusieurs images par requête ne posent aucun problème, et elles sont analysées ensemble : étiquetez-les (« Image 1 », « Image 2 ») et les tours suivants pourront s’y référer par leur nom. Trois manières de transporter les octets :

Streaming : réglez stream à true et la réponse arrive en server-sent events dans un ordre fixe — message_start, puis pour chaque bloc de contenu un start, un ou plusieurs deltas et un stop, puis message_delta et message_stop.

Deux choses peuvent encore vous surprendre en plein flux. Des événements ping peuvent apparaître n’importe où. Et des erreurs peuvent apparaître après un HTTP 200 sain — une overloaded_error, normalement un 529, peut arriver sous forme d’événement dans le flux.

Deux faits sur les deltas d’appel d’outil méritent leur propre répétition. Les deltas (input_json_delta) transportent des fragments d’une chaîne JSON, pas des objets JSON ; seule l’entrée tool_use assemblée à la fin est un objet. Et les SDK exigent le streaming pour les très grandes valeurs de max_tokens, parce que les appels HTTP simples expirent.

Un scénario de coût à connaître par cœur. Un document de référence de 40 000 tokens est consulté toutes les 20–30 minutes — plus longtemps que la durée de vie par défaut du cache. La réponse est le prompt caching avec l’option TTL d’une heure sur le point d’arrêt du cache : vous payez double pour l’écriture une fois, puis un dixième du tarif d’entrée à chaque lecture ensuite. Deux précisions en petits caractères : ajouter un second point d’arrêt n’étend pas les cinq minutes par défaut, et le caching automatique ne change pas vos options de TTL.

04La surface REST

Sous les SDK, l’API Claude est un service REST en JSON sur HTTPS, et l’examen attend que vous la connaissiez à l’état brut.

Les appels bruts exigent trois en-têtes à chaque fois : un en-tête d’autorisation (Authorization: Bearer, ou l’ancien x-api-key pour les clés Console), anthropic-version qui épingle la date d’API pour laquelle votre code a été construit, et content-type: application/json.

Un quatrième — anthropic-workspace-id — n’entre en scène que lorsqu’une clé API multi-workspaces est en jeu. Les SDK officiels envoient automatiquement les trois standards ; l’en-tête workspace, c’est à vous de le passer. Et journalisez l’en-tête request-id de la réponse — c’est l’identifiant que le support demande quand quelque chose tourne mal.

Les limites de débit s’expriment, par palier d’usage, en requêtes par minute et en tokens par minute, avec un plafond de dépense mensuel par-dessus — une raison pour laquelle l’endpoint de comptage de tokens gagne sa place avant les grosses soumissions. Les endpoints de liste paginent vers l’avant avec un curseur opaque ; la pagination automatique des SDK ne va que vers l’avant.

05Portées d’instructions et conception de schémas

Un sous-domaine ici parle en réalité de surfaces de configuration : les fichiers CLAUDE.md et les fichiers de settings qui entourent Claude Code et l’Agent SDK. La version courte — l’analyse détaillée se trouve sur la page du domaine Claude Code : les instructions que vous écrivez vivent dans une hiérarchie — gérée par l’organisation, utilisateur, projet, projet-local — et la mémoire automatique est tout autre chose : les notes que Claude écrit lui-même.

Une seule règle tranche la moitié des questions de ce territoire : CLAUDE.md façonne le comportement, settings.json l’impose. Une politique qui doit tenir — commandes bloquées, sandboxing, modèles autorisés — va dans les paramètres gérés, pas dans la prose.

L’autre moitié, c’est la conception de schémas pour la sortie structurée. Le décodage contraint de l’API prend en charge un sous-ensemble de JSON Schema ; les helpers des SDK retirent donc les contraintes qu’ils ne peuvent pas imposer — minimum et maximum, limites de longueur de chaîne — les réexpriment dans les descriptions de champs, et posent additionalProperties: false partout.

Votre code valide ensuite les réponses par rapport au schéma d’origine — et c’est là que ces contraintes retirées mordent vraiment. Le pattern à retenir : chaque champ requis, additionalProperties false, les intervalles documentés dans les descriptions et vérifiés de votre côté.

06Sessions et reprise

Un fait d’intégration que l’examen aime bien. Dans l’Agent SDK, une application multi-tenant qui garde une session par conversation d’utilisateur devrait conserver chaque ID de session et le passer à resume quand cet utilisateur revient.

L’option continue attrape simplement la session la plus récente du répertoire courant — la mauvaise sémantique pour du multi-tenant. Et le forking sert à dériver une session en alternatives, pas à retrouver son chemin.

07Une page pour réviser

Six sous-domaines de prose se trouvent au-dessus de cette ligne. Voici le même domaine en deux tableaux et une liste de contrôle — le cycle de vie que l’examen teste au mot près, et l’outil que chaque scénario coût-et-latence réclame. Si vous ne relisez qu’une chose la veille, relisez ceci.

La liste de contrôle de la veille. Vous devriez pouvoir énoncer chacune de ces lignes sans regarder :

• —Les quatre états du cycle de vie dans l’ordre, et lequel est la seule vraie échéance.
• —L’engagement de préavis : 60 jours minimum — et 30, 90 et 180 sont les leurres.
• —L’absence d’état en une phrase — et ce qu’elle vous oblige à renvoyer, à chaque requête.
• —Les trois routes pour les octets d’image, et quand chacune gagne.
• —Les cinq valeurs de stop_reason, et celle qui veut dire « inachevé — renvoyer tel quel ».
• —Les trois en-têtes de chaque appel brut, et le quatrième que les SDK n’enverront pas pour vous.
• —La règle unique : CLAUDE.md façonne le comportement, settings.json l’impose.

Une ligne à tracer à travers tout cela : les idées sont stables, les chiffres ne le sont pas. L’absence d’état, la discipline du cycle de vie, l’échelle de l’architecture la moins complexe, la règle du façonne-impose — tout cela survivra à n’importe quel changement de produit. Les faits datés — les plafonds de taille, la liste des endpoints, les modèles qui acceptent un message system en milieu de conversation — ont été vérifiés auprès de la documentation officielle en septembre 2026, et ils sont du genre de détail qui peut changer entre deux éditions de l’examen. Revérifiez-les auprès de la documentation vivante la semaine où vous passez l’examen.

08Les pièges de ce domaine

• —« Déprécié veut dire cassé » — non. Les modèles dépréciés répondent normalement jusqu’à la date de retrait.
• —« La date de retrait d’Anthropic s’applique sur Bedrock » — les plateformes partenaires tiennent leurs propres calendriers.
• —« L’API se souvient de notre conversation » — sans état. Renvoyez tout, à chaque requête.
• —« Un 200 veut dire que le flux a réussi » — des erreurs peuvent arriver sous forme d’événements dans le flux.
• —« Chaque delta d’appel d’outil est du JSON analysable » — ce sont des fragments de chaîne ; assemblez d’abord.
• —« Les SDK envoient chaque en-tête pour moi » — les trois standards, oui ; l’en-tête workspace, non.
• —« count_tokens est un drapeau de l’appel messages » — c’est un endpoint séparé, avec son propre plafond.
• —« continue trouvera la session du bon utilisateur » — il prend la session la plus récente du répertoire. Conservez l’ID ; reprenez avec lui.

09Vérifiez vos acquis

Six questions — une par sous-domaine, dans l’ordre où la page les a traités. Chacune se déplie pour révéler la réponse et, plus utile encore, la raison pour laquelle les mauvaises options sont mauvaises.