Aller au contenu principal

Cours complet

Développeur Backend + IA

Fonctionnalités IA dans des systèmes backend fiables

API LLM, RAG, outils, files de tâches, observabilité, évaluation et architecture de production.

Terminez le cours avec mieux qu’une démo qui survit à une seule requête réussie : construisez un dossier de preuves de production pour un backend IA avec contrats typés, retries et idempotence, streaming contrôlé, RAG avec contrôles ACL et fraîcheur, actions d’outils bornées, gate d’évaluation, observabilité, budgets de coût et chemin de rollback testé.

0%0/9 leçons

La progression est enregistrée localement dans votre navigateur.

10–16 semaines3 modules9 leçons1 évaluations

Système opératoire d’étude

Comment suivre le cours et conserver un résultat tangible

1. Commencer par le contrat

Pour chaque fonctionnalité IA, définissez d’abord le schéma d’entrée/sortie, le budget de timeout, la politique de retry, la clé d’idempotence, la taxonomie d’erreurs et la source autoritative. Un prompt sans contrat de transport et d’application n’est pas encore un backend.

2. Reproduire la panne

Ajoutez au happy path timeout, 429/5xx du fournisseur, sortie structurée malformée, requête dupliquée, annulation client et retrieval obsolète. Chaque panne doit se terminer dans un état système prévisible.

3. Vérifier l’effet de bord

Si le modèle propose une action d’outil, la couche applicative vérifie indépendamment identité, autorité, schéma, préconditions et idempotence. Le texte du modèle n’est pas une permission d’exécuter une action.

4. Conserver les preuves de production

Enregistrez traces, latence, retries, preuves de retrieval, décisions d’outils, coût par tâche réussie et résultats de régression. « Cela a répondu en local » reste une stack d’observabilité remarquablement modeste.

Règles du cours

Ne pas seulement lire — le prouver

  • HTTP 200 du fournisseur de modèle ne signifie pas que le résultat métier est correct ; transport, schéma, sémantique et autorité sont contrôlés séparément.
  • Retry sans idempotence ni réconciliation est un générateur d’effets de bord dupliqués, pas un reliability pattern.
  • Ne donnez jamais au modèle une autorité que le caller authentifié ne possède pas ; un tool schema ne remplace pas un contrôle de permission.
  • Évaluez RAG séparément aux couches retrieval et réponse : une réponse pertinente provenant du ACL scope d’un autre utilisateur reste une panne.
  • Après un incident de production, la reproduction minimale devient un cas de régression permanent avant tout prochain changement de modèle, prompt, retrieval ou outil.

Module 1

Socle IA commun

Fondamentaux et contrôle des résultats.

RésultatUne utilisation sûre et vérifiable de l’IA.
  1. Culture IA et limites des modèles

    Essentiel

    Capacités, hallucinations, limites de contexte, confidentialité et usage responsable.

  2. Prompt et context engineering

    Essentiel

    Instructions, contraintes, exemples et vérification des résultats.

    Prérequis: Culture IA et limites des modèles

  3. Sorties structurées et évaluation

    Essentiel

    Schémas de réponse, checks déterministes et cas de test.

    Prérequis: Prompt et context engineering

Checkpoint après le module

Baseline du contrat backend IA

  • ✓ les contrats d’entrée/sortie et la taxonomie des pannes sont documentés
  • ✓ un signal de vérification est défini pour chaque réponse IA
  • ✓ les frontières de confidentialité et d’autorité sont marquées avant l’intégration

Laboratoire de transfert de scénario

Transfer lab : transformer un endpoint IA en contrat backend

Prenez un endpoint qui ne fait aujourd’hui que transmettre un prompt au modèle. Décomposez-le en contrat de transport, contrat du modèle, vérification, frontière de données et états de panne afin qu’un autre ingénieur backend puisse implémenter le client sans connaître le prompt magique.

Livrable

Contrat API + diagramme de séquence + matrice de pannes couvrant timeout, retry, sortie malformée, annulation, frontière de confidentialité et owner de chaque contrôle autoritatif.

  • ✓ la validation du schéma précède la logique métier
  • ✓ retry n’est autorisé que pour des classes de panne explicitement définies
  • ✓ la frontière de confidentialité et d’autorité n’est pas déléguée au prompt
  • ✓ les champs critiques disposent d’un signal de vérification déterministe ou autoritatif

Module 2

Intégration des API LLM

Contrats, streaming et fiabilité.

RésultatUn client IA prêt pour la production.
  1. Contrats d’API LLM

    Essentiel

    Schémas typés, validation, timeouts, retries et idempotence.

  2. Streaming et backpressure

    Essentiel

    Réponses partielles, annulation et contrôle de flux.

  3. Projet : API IA en production

    Projetpratique + évaluation

    Sorties structurées, retries, traces, tests et rapport de coûts.

Checkpoint après le module

Client API LLM résilient

  • ✓ timeouts, retries, backoff et annulation disposent de tests exécutables
  • ✓ une requête dupliquée ne crée pas un effet de bord dupliqué
  • ✓ la sortie structurée est validée avant la logique métier et le streaming ne contourne pas la validation finale

Laboratoire de transfert de scénario

Transfer lab : retries, idempotence et streaming sous charge

Construisez un client API IA résilient et cassez volontairement le réseau et le chemin fournisseur : 429, 5xx, stream lent, déconnexion après une réponse partielle et requête répétée après un résultat inconnu. Prouvez que retry ne multiplie pas les effets de bord et ne masque pas une panne terminale.

Livrable

Client exécutable + tests d’injection de panne + rapport de traces avec tentatives, backoff, annulation, clé d’idempotence, état final, latence p95 et coût par tâche réussie.

  • ✓ une livraison dupliquée ne crée pas une écriture ou action dupliquée
  • ✓ l’annulation client arrête réellement le travail ou le réconcilie
  • ✓ une sortie de streaming partielle n’est jamais traitée comme résultat final validé
  • ✓ latence et coût sont mesurés par tâche réussie en incluant les retries

Module 3

RAG, outils et production

Connaissance, actions, quality gates et monitoring.

RésultatUne fonctionnalité IA avec SLO, évaluations et rollback.
  1. Architecture d’un service RAG

    Essentiel

    Retrieval, citations, ACL et fraîcheur.

  2. Tool calling et permissions

    Essentiel

    Outils typés, validations et audit trail.

  3. Jalon : fonctionnalité IA en production

    Jalon

    Évaluations, revue de sécurité, monitoring et rollback.

Checkpoint après le module

Fonction IA de production gouvernée

  • ✓ RAG vérifie ACL, fraîcheur et citations
  • ✓ les actions d’outils ont une autorité explicite et une postcondition autoritative
  • ✓ les gates qualité, latence, coût et sécurité peuvent arrêter le rollout et le rollback a été testé

Laboratoire de transfert de scénario

Transfer lab : RAG + action d’outil avec gate de production

Construisez un flux backend où retrieval forme un dossier de preuves, le modèle propose une action d’outil bornée et la couche applicative vérifie permission et état final. Modifiez ensuite retrieval ou la configuration du modèle et exécutez les régressions avant le canary.

Livrable

Trace end-to-end : identité → requête → ACL/filtre → preuves classées → décision structurée → préconditions outil → action → postcondition autoritative → résultat d’évaluation → décision de release.

  • ✓ retrieval ne renvoie aucun ACL scope interdit et les preuves obsolètes ont une politique explicite
  • ✓ la sortie du modèle n’exécute aucun outil sans contrôle d’autorité côté application
  • ✓ l’effet de bord est confirmé par une postcondition autoritative ou passe en état de réconciliation
  • ✓ une régression critique bloque le rollout, quelle que soit l’élégance de la démo

Contrat capstone

Capstone : service backend IA gouverné

Construisez une fonctionnalité IA de style production comme service backend avec contrat API, étape fournisseur/modèle, retrieval ou outils, contrôles déterministes, évaluation, observabilité et rollback. Le but est de prouver un comportement contrôlé sous panne, pas de livrer un autre chat en thème sombre.

Ce qu’il faut remettre

  • — contrat OpenAPI ou API typée, schémas métier, taxonomie d’erreurs et politique timeout/retry/idempotence
  • — architecture + diagramme de séquence couvrant les frontières identité, données, modèle, retrieval/outils et système autoritatif
  • — suite exécutable d’injection de pannes pour 429/5xx, timeout, annulation, sortie malformée, livraison dupliquée, retrieval obsolète et effets de bord partiels
  • — preuves RAG/outils pour ACL, fraîcheur et citations ou traces permission, précondition et postcondition
  • — dataset d’évaluation + rapport de régression avec seuils qualité, sécurité et correction métier
  • — dossier d’observabilité avec latence, erreurs, retries, coût tokens/fournisseur, coût par tâche réussie et traces échantillonnées
  • — rollout progressif + critères canary, rollback et kill + runbook incident-vers-régression

Quand le résultat peut être considéré comme prêt

  • ✓ l’API renvoie un résultat métier validé ou une panne typée contrôlée, pas du « presque JSON »
  • ✓ retry, idempotence et réconciliation empêchent les effets de bord dupliqués cachés
  • ✓ le chemin RAG/outils préserve identité, ACL et frontières d’autorité de la requête à l’état final
  • ✓ une régression critique de qualité ou sécurité bloque le release avant le canary
  • ✓ SLO et budget sont évalués par tâche réussie en incluant retries et coût de revue
  • ✓ rollback ou fallback restaure un envelope fonctionnel connu et conserve les preuves d’audit

Pratique finale et évaluation

Le cours se termine par un artefact pratique et une grille d’acceptation. Le résultat est considéré comme terminé après validation des critères d’acceptation, et non après la simple lecture des contenus.