Fondamentaux•6–10 heures

Client d’API IA résilient

Construisez un client d’API LLM prêt pour la production avec sortie structurée, validation, retries, timeouts, idempotence, tracing et tests.

typage Pythonasync IOPydanticretriesobservabilitétests

Scénario

Tâche

Un service interne doit appeler un LLM pour classifier des demandes de support. Les réponses doivent être structurées, les requêtes répétées sûres et les erreurs mesurables et reproductibles.

Exécution pas à pas

1. Définir le contrat

Résultat: Les requêtes et réponses ont une forme typée stable.

Tâches

→Définir le modèle d’entrée
→Créer le schéma de sortie
→Définir les erreurs de validation
→Ajouter un correlation ID

Vérifications

✓Une réponse invalide ne passe jamais silencieusement
✓Le schéma possède des tests unitaires

2. Implémenter la couche transport

Résultat: Le client contrôle explicitement le comportement réseau.

Tâches

→Ajouter un chemin de requête asynchrone
→Configurer les timeouts de connexion et lecture
→Gérer les réponses 429 et 5xx
→Ajouter un backoff exponentiel avec jitter

Vérifications

✓Les retries sont bornés
✓Les erreurs non retryables ne sont pas répétées

3. Ajouter l’observabilité

Résultat: Chaque appel peut être expliqué après son exécution.

Tâches

→Journaliser le request ID
→Mesurer la latence
→Enregistrer l’usage des tokens et le nombre de retries
→Ne pas journaliser les secrets ni les PII

Vérifications

✓Une requête est traçable de bout en bout
✓Les données sensibles ne sont pas présentes dans les logs

4. Construire les tests et simuler les pannes

Résultat: Les modes de panne connus sont reproductibles localement.

Tâches

→Simuler un timeout
→Simuler une réponse 429
→Retourner un JSON malformé
→Tester une requête dupliquée

Vérifications

✓Tous les chemins d’échec ont des assertions
✓Une requête idempotente répétée ne crée pas de doublon

Critères d’acceptation

Les types passent la validation
Tous les tests sont verts
Les retries sont bornés
Une sortie structurée invalide renvoie une erreur explicite
Un rapport latence/retries/coût existe

Grille d’évaluation

Comment le résultat est évalué

Score de réussite: 70/100 · Distinction: 90/100

Contrats et validation

Les requêtes, réponses et erreurs ont une forme typée explicite.

25 points

Insuffisant

Le schéma est incomplet ou les erreurs sont masquées.

Compétent

Les contrats principaux sont typés et testés.

Solide

Les contrats sont versionnés et les modes de panne ont des types et tests dédiés.

Preuves requises

✓ Lien vers le code ou l’artefact
✓ README court expliquant les décisions
✓ Sortie des tests ou preuve runtime
✓ Exemples de réponses valides et invalides

Fiabilité de la couche transport

Timeouts, retries, backoff, rate limits et idempotence sont implémentés avec des limites sûres.

30 points

Insuffisant

Les retries sont illimités ou les erreurs retryables et non retryables sont mélangées.

Compétent

Les politiques de retry et timeout sont bornées et testées.

Solide

Jitter, circuit breaker ou fallback multi-modèles sont démontrés avec des preuves.

Preuves requises

✓ Lien vers le code ou l’artefact
✓ README court expliquant les décisions
✓ Sortie des tests ou preuve runtime
✓ Simulation de panne pour timeout, 429 et 5xx

Observabilité

Chaque appel est explicable via request ID, latence, retries, usage et logs sûrs.

20 points

Insuffisant

Il n’existe pas de corrélation de bout en bout ou des données sensibles apparaissent dans les logs.

Compétent

Request ID, latence, usage et redaction sont implémentés.

Solide

Des traces distribuées, dashboards ou seuils d’alerte sont implémentés.

Preuves requises

✓ Lien vers le code ou l’artefact
✓ README court expliquant les décisions
✓ Sortie des tests ou preuve runtime
✓ Exemple de trace ou log structuré

Tests et reproductibilité

Les chemins de succès et d’échec sont reproductibles automatiquement.

25 points

Insuffisant

Seul le happy path est testé.

Compétent

Des tests unitaires et d’intégration couvrent les principaux modes de panne.

Solide

Des tests de concurrence/charge et des fixtures de régression stables sont inclus.

Preuves requises

✓ Lien vers le code ou l’artefact
✓ README court expliquant les décisions
✓ Sortie des tests ou preuve runtime
✓ Matrice de tests pour les scénarios clés