AI Engineer Path — Achref
Parcours structuré pour pivoter de PHP/TypeScript/NestJS vers AI Engineer freelance (RAG / Agentic / MCP / Voice) sur le marché français en 2026.
Objectif: TJM 1000-1500€/jour d'ici 12 mois, positionné sur 1 verticale.
Où j'en suis
- [ ] Phase 0 : Owning Dravos — maîtrise du code Python de Dravos (4 semaines, fluent à 100%)
- [ ] Vertical choisi (finance / legal / RH / e-commerce / immobilier / autre)
- [ ] Phase 1 : Fundamentals + Anthropic Prompt Engineering course
- [ ] Phase 2 : Projet RAG prod-grade déployé (idée : extension de Dravos)
- [ ] Phase 3 : Projet Agentic + MCP server custom (idée : extraire un MCP de Dravos)
- [ ] Phase 4 : Projet Voice agent
- [ ] Phase 5 : Profil LinkedIn / Malt / CdlC actif + 1ère mission
→ Voir 00-overview-and-timeline.md pour le plan détaillé.
Structure du repo
ai-engineer-path/
├── README.md ← tu es ici
├── 00-overview-and-timeline.md ← plan + timeline 6 phases
│
├── 01-fundamentals/ ← théorie LLM (EN)
│ ├── 01-llm-basics.md
│ ├── 02-embeddings-vector-db.md
│ ├── 03-python-for-ts-devs.md
│ └── courses-to-take.md ← liste cours externes ORDONNÉE
│
├── 02-rag-production/ ← RAG prod-grade (EN)
│ ├── 01-concepts-architecture.md
│ ├── 02-build-rag-system.md ← spec projet 1
│ ├── 03-eval-observability.md
│ └── 04-advanced-hybrid-rerank.md
│
├── 03-agentic-and-mcp/ ← Agents + MCP (EN)
│ ├── 01-tool-use-function-calling.md
│ ├── 02-langgraph.md
│ ├── 03-mcp-protocol.md ← critique 2026
│ ├── 04-build-custom-mcp-server.md ← spec projet 2
│ └── 05-multi-agent-orchestration.md
│
├── 04-voice-agents/ ← Voice (EN)
│ ├── 01-realtime-api.md
│ ├── 02-livekit-elevenlabs.md
│ └── 03-build-voice-agent.md ← spec projet 3
│
├── 10-vertical-positioning.md ← choix verticale (FR)
├── 11-portfolio-checklist.md ← skills à valider
├── 12-certifications.md ← cert cloud à viser (FR)
├── 13-freelance-strategy-fr.md ← LinkedIn / Malt / pricing (FR)
├── 14-resources.md ← blogs / papers / repos
├── 15-owning-dravos.md ← ⭐ DÉFENDRE Dravos (asset #1) (FR)
│
├── projects/ ← le CODE des projets portfolio
│ ├── 01-rag-prod/
│ ├── 02-agentic-mcp-server/
│ └── 03-voice-agent/
│
└── _notes/ ← notes perso, brouillonsComment utiliser ce repo
- Lis 15-owning-dravos.md EN PREMIER (45 min). C'est ton asset #1 et ton plus gros différenciateur. Tu pars de Dravos, pas de zéro.
- Lis 00-overview-and-timeline.md en entier (15 min). Choisis ta verticale.
- Lis 13-freelance-strategy-fr.md (le plus actionnable maintenant — peut être commencé sans skills techniques).
- Suis l'ordre des phases dans
00-overview-and-timeline.md. Pour chaque phase: lis la théorie (dossiers numérotés) → suis le cours externe linké → code le projet. - Le code des projets va dans
projects/— chaque projet aura son propreREADME.md, son repo git, son déploiement. - Coche les cases dans README.md +
11-portfolio-checklist.mdau fur et à mesure. - Utilise Claude (moi) comme pair-programmer 24/7 quand tu codes. Je guide, tu tapes.
Règle de discipline #1
Les docs sont le GPS, pas la voiture. Tu n'apprends pas en lisant ces fichiers. Tu apprends en :
- Suivant les cours externes (DL.AI, Anthropic, etc.)
- Codant les 3 projets toi-même
- Postant 2× / semaine sur LinkedIn
Sans ça, ce repo est inutile.
Stack cible (mai 2026)
| Couche | Stack | Pourquoi (vision senior) |
|---|---|---|
| Frontend | Vercel AI SDK + Next.js 15 | Streaming SSE natif, useChat/useObject, zéro glue ; standard de fait côté UI. |
| Backend | LangGraph (Python) OU raw SDK Anthropic + MCP servers | LangGraph pour les graphes stateful ; raw SDK quand tu veux maîtriser coût/latence. |
| Vector DB | pgvector (par défaut) / Qdrant (souveraineté, gros volumes) | pgvector = une seule base à opérer ; Qdrant quand le filtrage + scale l'exigent. |
| LLMs | Anthropic (défaut) + OpenAI + Mistral (souveraineté FR) | Routing par tier (voir matrice ci-dessous) ; abstraire le provider derrière une interface. |
| Voice | OpenAI Realtime API + LiveKit + ElevenLabs | Realtime pour la latence speech-to-speech ; LiveKit pour le transport WebRTC. |
| Eval | Ragas + LangSmith (ou Braintrust) | Pas de « ça marche sur mon prompt » : un harnais d'éval avant la prod. |
| Cloud | GCP (1 cert : Generative AI Leader) | Une seule cert, ciblée vente/positionnement, pas pour le badge. |
| Observability | LangSmith / OpenTelemetry + logging usage | Tracer chaque appel : tokens, coût, latence p95, taux d'erreur, cache hit-rate. |
→ Détails et justifications dans chaque dossier numéroté.
Matrice de routing modèle Anthropic (à connaître par cœur)
C'est la décision d'architecture qui pilote ton coût en prod. Un staff engineer ne met pas le flagship partout — il route par tier selon la tâche.
| Modèle | Model ID (exact) | Prix in / out (USD / Mtok) | Contexte | Quand l'utiliser |
|---|---|---|---|---|
| Claude Opus 4.8 | claude-opus-4-8 | 5 / 25 (à 1M ctx) | 1M | Agentique long-horizon, raisonnement dur, code review, le « cerveau » d'un orchestrateur. |
| Claude Sonnet 4.6 | claude-sonnet-4-6 | 3 / 15 | 1M | Le cheval de trait : RAG, extraction, génération, le 80 % des appels. |
| Claude Haiku 4.5 | claude-haiku-4-5 | 1 / 5 | 200K | Classification, routing, sous-agents, pré-filtrage, reformulation de requête. |
⚠️ Pièges de correctness fréquents en entretien / en prod (2026) — un junior se fait avoir, pas toi :
- Les model IDs n'ont pas de suffixe de date : c'est
claude-opus-4-8, jamaisclaude-opus-4-8-20260101. Un ID inventé renvoie un 404.- L'extended thinking à budget fixe est mort sur Opus 4.7/4.8.
thinking: {type: "enabled", budget_tokens: N}renvoie un 400. On utilise le thinking adaptatif + le paramètreeffort.temperature/top_p/top_ksont retirés sur Opus 4.7/4.8 → 400 si tu les envoies. On pilote par le prompt et l'effort.
# La forme CORRECTE en 2026 (Opus 4.8, thinking adaptatif + effort)
from anthropic import Anthropic
client = Anthropic() # lit ANTHROPIC_API_KEY depuis l'env — jamais de clé en dur
resp = client.messages.create(
model="claude-opus-4-8",
max_tokens=16000,
thinking={"type": "adaptive"}, # PAS de budget_tokens
output_config={"effort": "high"}, # low | medium | high | xhigh | max
messages=[{"role": "user", "content": "..."}],
)
print(resp.usage) # logge TOUJOURS usage → coût, cache hit-rate, tokens🧠 Le modèle mental : comment un AI Engineer senior raisonne
Avant de coder quoi que ce soit, internalise ces axes. Ce sont les questions qu'un client à 1200€/jour attend que tu poses avant lui.
1. La pyramide de complexité (ne sur-architecture jamais)
┌─────────────────────┐
│ Agent autonome │ ← coût/latence max, dernier recours
├─────────────────────┤
│ Workflow orchestré │ ← TOI tu pilotes la boucle (tool use)
├─────────────────────┤
│ Appel LLM simple │ ← classer, résumer, extraire, RAG
└─────────────────────┘Règle senior : descends toujours au tier le plus bas qui résout le problème. « On a mis un agent multi-step » est rarement la bonne réponse à « extraire 3 champs d'un PDF ». L'agent ne se justifie que si : tâche multi-étapes mal spécifiable d'avance ET la valeur paye le surcoût ET l'erreur est rattrapable (tests, review, rollback).
2. Les 5 préoccupations de prod (le « non-fonctionnel » qui te démarque)
| Axe | La question que tu te poses | Le levier concret |
|---|---|---|
| Coût | Combien coûte 1 000 requêtes ? Quel est mon hit-rate de cache ? | Prompt caching (cache_control), routing Haiku/Sonnet/Opus, usage loggé. |
| Latence | Quel est mon p95 ? Time-to-first-token ? | Streaming, effort plus bas, parallélisation (asyncio.gather), pré-warm cache. |
| Observabilité | Si un appel échoue à 3h du matin, je trace quoi ? | Tracing par appel (LangSmith/OTel), request_id, logs de usage et stop_reason. |
| Sécurité | Une prompt injection peut-elle exfiltrer un secret ou déclencher une action ? | Tools gatés (confirmation humaine), secrets jamais dans le prompt, validation aux frontières. |
| Scale | Que se passe-t-il à 100 req/s ? Rate limits ? Backpressure ? | AsyncAnthropic, max_retries, exceptions typées, file d'attente, batching. |
3. La discipline d'éval (ce qui sépare le bricoleur du senior)
Tu ne livres jamais un système RAG/agentique sans harnais d'éval. « Ça marche sur mes 3 exemples » n'est pas une preuve. Tu construis un golden set, tu mesures (Ragas : faithfulness, context recall, answer relevancy), et tu défends le chiffre. C'est exactement ce qu'un client paye au TJM senior.
⚠️ Failure modes — ce qui casse en prod (et que tu dois anticiper)
| Symptôme observé | Cause racine probable | Le fix senior |
|---|---|---|
| Réponses RAG hallucinées / hors-sujet | Mauvais chunking, pas de reranking, contexte non pertinent injecté | Hybrid search (BM25 + dense) + reranker ; mesurer context_precision. |
| Coût qui explose en prod | Flagship partout, zéro cache, contexte gonflé à chaque appel | Routing par tier + prompt caching ; vérifier cache_read_input_tokens > 0. |
| Latence p95 inacceptable | Appels séquentiels, pas de streaming, effort trop haut | asyncio.gather sur les tool calls parallèles, streaming, baisser l'effort. |
400 mystérieux après upgrade modèle | budget_tokens / temperature envoyés sur Opus 4.7/4.8 | Passer au thinking adaptatif + effort ; retirer les params d'échantillonnage. |
Cache hit-rate à zéro malgré cache_control | Invalidateur silencieux (timestamp, UUID, JSON non trié) dans le préfixe | Geler le préfixe (system + tools), pousser le volatile après le dernier breakpoint. |
| Agent qui boucle / explose le budget | Pas de garde-fou sur le nombre d'itérations / task_budget | Borne dure (max_tokens), garde-fou d'itérations, task_budget (beta). |
| Tool call qui exfiltre des données | Bash brut + secret dans le prompt + prompt injection | Promouvoir l'action en tool dédié gaté ; secrets hors prompt (vault/env). |
🏋️ Exercices
Demandants et progressifs. Chacun doit produire du code qui tourne + une décision défendable. Ne passe pas au suivant tant que tu ne peux pas défendre tes chiffres.
Exercice 1 — Le routeur de modèle (fondation économique)
Objectif : écrire un classifieur de requête qui route vers Haiku / Sonnet / Opus et mesure le coût économisé.
Indice/Solution : un premier appel Haiku 4.5 classe la difficulté (simple / standard / hard) via structured output (output_config.format + schéma Pydantic), puis tu dispatches. Logge usage pour chaque tier et calcule le coût d'un batch de 1 000 requêtes vs « tout en Opus ». Défends le ratio. Attention : le coût du classifieur Haiku doit être < à l'économie réalisée, sinon le routing ne se justifie pas.
Exercice 2 — RAG prod-grade avec éval (le cœur du métier)
Objectif : construire un mini-RAG (pgvector) avec un harnais d'éval Ragas sur un golden set de 20 questions.
Indice/Solution : ingestion → chunking (teste 3 stratégies de taille) → embeddings → retrieval top-k → génération Sonnet 4.6 avec citations. Mesure faithfulness, context_recall, answer_relevancy. Le livrable n'est pas « ça répond » mais un tableau comparatif des 3 stratégies de chunking avec les métriques, et une recommandation justifiée.
Exercice 3 — Optimisation coût/latence (rends-le production-grade)
Objectif : prendre le RAG de l'Ex. 2 et diviser le coût par ≥ 2 et la latence p95 par ≥ 30 % sans dégrader faithfulness.
Indice/Solution : prompt caching sur le préfixe stable (system + instructions + few-shots) — vérifie cache_read_input_tokens > 0 sur 2 appels successifs. Passe le retrieval/reranking en asyncio.gather. Streame la génération. Baisse l'effort à medium et re-mesure l'éval : si faithfulness tient, tu as gagné. Produis un avant/après chiffré (coût, p95, métriques d'éval).
Exercice 4 — Casse-le puis répare-le (résilience)
Objectif : rendre le système robuste aux pannes provider (429, 529, timeout).
Indice/Solution : passe en AsyncAnthropic, configure max_retries, attrape les exceptions typées (RateLimitError, OverloadedError, APITimeoutError) — jamais de string matching sur le message. Ajoute un fallback de modèle (Opus → Sonnet) sur surcharge. Simule un 529 (mock) et prouve que la requête aboutit quand même. Mesure l'impact sur la latence p95.
Exercice 5 — MCP server custom + agent gaté (extraction de Dravos)
Objectif : extraire une capacité de Dravos en MCP server, l'exposer à un agent, et gater l'action irréversible.
Indice/Solution : définis un tool dédié (pas du bash brut) pour l'action sensible, avec confirmation humaine avant exécution (always_ask / human-in-the-loop). Le secret d'auth ne transite jamais par le prompt. Démontre une tentative de prompt injection qui échoue à déclencher l'action sans confirmation. C'est l'exercice qui vend ton asset #1.
Exercice 6 — Défends le chiffre (l'épreuve senior)
Objectif : rédiger une note d'archi d'1 page qui justifie chaque choix du système complet, chiffres à l'appui.
Indice/Solution : pour chaque couche, écris la décision, l'alternative écartée, et le nombre (coût/1k req, p95, faithfulness, hit-rate cache). Anticipe les 3 questions qu'un CTO sceptique posera. Si tu ne peux pas défendre un chiffre, c'est que tu n'as pas mesuré — retourne mesurer. C'est littéralement le format d'un entretien d'archi senior.
🎤 En entretien
Les questions que cette stack invite — avec la réponse senior en une ligne.
« Pourquoi pas un agent autonome partout ? » Parce que coût/latence/imprévisibilité : on descend au tier le plus bas (appel simple > workflow > agent) qui résout la tâche, l'agent ne se justifie que si la tâche est mal spécifiable d'avance et l'erreur rattrapable.
« Comment tu choisis entre Opus, Sonnet et Haiku ? » Routing par tier : Haiku 4.5 (1/5) pour classer/router/sous-agents, Sonnet 4.6 (3/15) pour le gros du RAG/extraction, Opus 4.8 (5/25) pour le raisonnement dur et l'orchestration — et je mesure le coût réel via
usage, je ne devine pas.« Ton système RAG répond bien — prouve-le. » Je ne « prouve » rien sans harnais d'éval : golden set + Ragas (
faithfulness,context_recall,answer_relevancy), et je compare les variantes (chunking, reranking) chiffres à l'appui — « ça marche sur 3 exemples » n'est pas une preuve.« Comment tu maîtrises le coût d'un système LLM en prod ? » Trois leviers : routing par tier, prompt caching sur le préfixe stable (et je vérifie
cache_read_input_tokens), et compression du contexte ; le tout observé en continu (tokens, coût, hit-rate loggés par appel).« Une prompt injection peut-elle faire mal à ton agent ? » Je gate les actions irréversibles derrière une confirmation (tool dédié, pas du bash brut), je garde les secrets hors du prompt (vault/env, jamais dans l'historique), et je valide aux frontières — la prompt injection ne doit pas pouvoir déclencher une action ni exfiltrer un secret.
Dernière mise à jour : 2026-06-16