Overview & Timeline — AI Engineer Path

Mon point de départ (mai 2026)

• Stack maîtrisé : PHP, TypeScript, NestJS, Next.js (côté Dravos), un peu de Python
• Expérience AI : a construit Dravos (plateforme SDLC agentique) avec Claude Code — comprend les concepts mais pas en profondeur, n'a jamais codé un RAG seul
• Forces uniques :
  • Stack TypeScript solide (différenciateur — 60-65% des AI engineers sont Python-only)
  • Expérience infra/DevOps (k3s, ArgoCD, Hetzner, Cloudflare)
  • Capacité à shipper end-to-end (full-stack + infra)
• Faiblesses à combler :
  • Pas de RAG prod-grade en portfolio
  • Pas de MCP server custom
  • Pas de voice agent
  • Profil LinkedIn pas positionné AI
  • Pas encore de réseau AI / pas de contenu publié

Mon objectif (calibré, mai 2026 → mai 2027 et au-delà)

TJM trajectory réaliste (calibré sur les baromètres FR 2026) :

Mois	TJM cible	Positionnement
0-6	600-800€	Full-Stack TS + Agents IA + AI-assisted solo builder (Dravos vitrine)
6-12	900-1100€	+ Python ajouté, 2 portfolio pieces, 1-2 missions
12-24	1200-1500€	Spécialisation verticale + track record + références
24+	1500-2000€	Expert reconnu (MCP / agentic / voice spé)

Erreur à éviter : vouloir sauter directement à 1400€ "parce que les experts y sont". Le marché classe selon ton ancienneté en IA, pas ton ancienneté totale. Tu débutes à ~1-2 ans d'IA perçue. Le 1400 c'est dans 18-24 mois, pas dans 6.

Positionnement : "AI Engineer & Solo Builder | Architected and shipped Dravos (autonomous SDLC platform) | Python + TypeScript + LangGraph + MCP | [verticale]"

Track record visé :

• Owning Dravos à 100% (fluent sur 119 fichiers Python)
• 2-3 missions livrées
• 1-2 extensions de Dravos (RAG, MCP server, voice agent)
• Réseau LinkedIn AI actif

Statut : freelance solo, transition progressive (garder PHP/Symfony en plancher revenu pendant 3-6 mois).

---

🧠 Le modèle mental : comment un staff engineer raisonne sur cette transition

Avant la timeline, le cadre. Trois lois structurent toute reconversion vers l'AI engineering, et la plupart des gens en ignorent au moins deux.

Loi 1 — Le marché price ton ancienneté perçue en IA, pas ton ancienneté totale

7 ans de dev ne te donnent pas 7 ans de crédibilité IA. Le recruteur/CTO te classe sur un axe séparé : « depuis combien de temps cette personne ship-t-elle des systèmes IA en prod ? ». Tu démarres ce compteur à ~0-1 an (Dravos te donne de l'avance, mais « fait avec Claude Code » plafonne la perception si tu ne sais pas défendre l'architecture). Conséquence opérationnelle : ta vitesse de progression de TJM est gouvernée par la vitesse à laquelle tu accumules des preuves vérifiables (projets déployés, métriques, articles, références), pas des heures de cours. Un staff engineer optimise le ratio preuve/heure, pas le volume d'apprentissage.

Loi 2 — Ton avantage est composé, donc défends-le au lieu de le diluer

Ton edge n'est pas « je connais l'IA » (commodité en 2026, tout le monde a accès aux mêmes modèles). Ton edge est l'intersection rare : TypeScript solide + infra/DevOps (k3s, ArgoCD) + capacité à shipper end-to-end + une verticale métier. Chaque axe pris seul est saturé ; l'intersection des quatre te place dans un percentile étroit. La tentation du débutant est de devenir « Python expert » — ça te déplace vers le centre saturé du marché et détruit ta prime d'intersection. Le bon move : Python juste assez pour LangGraph/data, et tout le reste investi à creuser l'intersection.

Loi 3 — Le portfolio est une machine à réduire le risque perçu par l'acheteur

Un client qui te paie 800-1500€/jour n'achète pas tes compétences, il achète une réduction d'incertitude sur le fait que le projet va aboutir. Chaque pièce de portfolio doit répondre à une objection précise du CTO :

Objection du CTO	La pièce qui la tue
« Sait-il faire du RAG qui scale, pas un notebook ? »	RAG prod déployé avec p95 latency, recall@5, coût/query
« Peut-il intégrer dans NOTRE stack ? »	MCP server custom exposable à Claude Desktop/Cursor
« Comprend-il les coûts/observabilité, ou va-t-il cramer mon budget LLM ? »	README avec coût/query (logué depuis resp.usage) + dashboard LangSmith/OTel
« Tient-il en prod ou ça casse au 1er edge case ? »	Eval Ragas + error handling + retries documentés

Si une pièce de portfolio ne tue pas une objection nommable, elle ne vaut rien (d'où l'anti-pattern « notebooks Colab → portfolio = zéro »).

La méta-règle : à chaque décision (quel cours, quel projet, quel post), pose-toi « quelle objection d'acheteur est-ce que je tue, et est-ce vérifiable de l'extérieur ? ». Si la réponse est « aucune » ou « non vérifiable », c'est du tutorial hell déguisé.

---

Les phases — timeline 12 mois (réaliste avec 12-15h/sem)

Phase 0a — Owning Dravos (semaines 1-4) ⭐ LE PLUS CRITIQUE

Output : Fluent à 100% sur Dravos. Capable de défendre chaque décision en entretien hostile.

• [ ] Lire 15-owning-dravos.md en entier
• [ ] Suivre le plan 4 semaines : modèles → agents → engine/Temporal → memory/sandbox/integrations
• [ ] Travailler le top 25 des questions d'entretien (mock interviews avec Claude)
• [ ] Notes complètes dans _notes/dravos-deep-dive.md
• [ ] Test final : walker n'importe quel module sur whiteboard sans regarder le code

Durée : 4 semaines, ~5h/sem.

Phase 0b — Positionnement (semaine 1, en parallèle) ✋

Output : Vertical choisi + profil LinkedIn updated + plan d'attaque clair.

• [ ] Choisir 1 verticale (voir 10-vertical-positioning.md)
• [ ] Update headline LinkedIn → "AI Engineer & Solo Builder | Built Dravos | [verticale]"
• [ ] Update bio LinkedIn (avec lien vers Dravos + mention "AI-assisted development")
• [ ] Créer profil Malt (même si pas encore prêt pour missions, prendre la place)
• [ ] Identifier 20 comptes LinkedIn à suivre (CTOs/AI engineers FR dans ta verticale)

Durée : 5-7 jours.

Phase 0c — Plancher revenu (continu) 💰

Output : 1-2 jours/sem de mission PHP/Symfony pour garder du revenu pendant la transition.

• [ ] Ne PAS couper les missions PHP existantes brutalement
• [ ] Réserver 60-70% du temps pour le parcours AI, 30-40% pour le PHP plancher
• [ ] Augmenter progressivement la part AI au fur et à mesure que les premiers contrats AI tombent

Phase 1 — Fundamentals (semaines 2-5)

Output : Comprendre LLMs, embeddings, RAG en profondeur. Premier code Python AI.

Cours obligatoires (parallèles) :

• [ ] Anthropic Prompt Engineering Tutorial (gratuit, 1 sem)
• [ ] DeepLearning.AI "Generative AI with LLMs" (~50€, 3 sem) — base théorique
• [ ] HuggingFace NLP Course chap 1-4 (gratuit) — embeddings, transformers

Lectures (ce repo, dossier 01-fundamentals/) :

• [ ] 01-llm-basics.md
• [ ] 02-embeddings-vector-db.md
• [ ] 03-python-for-ts-devs.md

Exercices :

• [ ] Faire un petit script Python qui compare 5 embeddings models sur 100 docs (recall@5 mesuré, pas à l'œil)
• [ ] Implémenter un "naive RAG" (50 lignes) sans framework, juste avec le SDK Anthropic (anthropic) + numpy — modèle claude-opus-4-8, thinking={"type": "adaptive"}, et logger resp.usage (input/output/cache tokens) pour calculer le coût/query dès la v0

Durée : 4 semaines.

Phase 2 — Projet 1 : RAG prod-grade (semaines 6-11)

Output : Projet déployé publiquement + article Medium/dev.to + post LinkedIn.

Cours :

• [ ] DeepLearning.AI "LangChain for LLM Application Development" (gratuit, 1 sem)
• [ ] DeepLearning.AI "Building and Evaluating Advanced RAG" (gratuit, 1 sem)

Lectures :

• [ ] 02-rag-production/01-concepts-architecture.md
• [ ] 02-rag-production/02-build-rag-system.md ← spec du projet 1
• [ ] 02-rag-production/03-eval-observability.md
• [ ] 02-rag-production/04-advanced-hybrid-rerank.md

Build (dans projects/01-rag-prod/) :

• [ ] Source data (publique ou propre — pas les docs Dravos privés)
• [ ] Pipeline : chunking → embeddings → pgvector → hybrid search + rerank → LLM
• [ ] Eval avec Ragas (faithfulness, answer_relevancy, context_precision)
• [ ] Observability via LangSmith ou OpenTelemetry
• [ ] Docker + déploiement (Vercel front + ton k3s pour back ?)
• [ ] README avec métriques réelles : p95 latency, recall@5, coût/query

Distribution :

• [ ] Article Medium / dev.to : "How I built a production RAG system in [vertical]"
• [ ] Post LinkedIn avec démo vidéo (30 sec)

Durée : 6 semaines.

Phase 3 — Projet 2 : Agentic + MCP custom (semaines 12-17)

Output : Système agentique multi-étapes avec MCP server custom écrit par toi.

Cours :

• [ ] DeepLearning.AI "AI Agents in LangGraph" (gratuit, 1 sem)
• [ ] Anthropic MCP tutorials (gratuit, 1 sem) — CRITIQUE 2026

Lectures :

• [ ] 03-agentic-and-mcp/01-tool-use-function-calling.md
• [ ] 03-agentic-and-mcp/02-langgraph.md
• [ ] 03-agentic-and-mcp/03-mcp-protocol.md
• [ ] 03-agentic-and-mcp/04-build-custom-mcp-server.md ← spec du projet 2
• [ ] 03-agentic-and-mcp/05-multi-agent-orchestration.md

Build (dans projects/02-agentic-mcp-server/) :

• [ ] Idée concrète : ex. agent qui analyse les contrats d'un cabinet d'avocat, ou agent qui prépare des reportings finance
• [ ] Implémentation LangGraph multi-étapes (state machine)
• [ ] MCP server custom (1 server, 3-5 tools) — exposable à Claude Desktop / Cursor
• [ ] Tool use + memory + retries + error handling
• [ ] Demo claire (Loom video ou Streamlit UI)

Distribution :

• [ ] Article : "Building a custom MCP server for [vertical] in TypeScript/Python"
• [ ] Post LinkedIn

Durée : 6 semaines.

Phase 4 — Projet 3 : Voice agent (semaines 18-22)

Output : Voice agent end-to-end (téléphonique ou web), démo accessible.

Cours :

• [ ] OpenAI Realtime API documentation + tutorials (gratuit, 1 sem)
• [ ] LiveKit Agents quickstart (gratuit, 1 sem)

Lectures :

• [ ] 04-voice-agents/01-realtime-api.md
• [ ] 04-voice-agents/02-livekit-elevenlabs.md
• [ ] 04-voice-agents/03-build-voice-agent.md ← spec du projet 3

Build (dans projects/03-voice-agent/) :

• [ ] Cas d'usage vertical : ex. assistant vocal de prise de RDV pour PME, ou agent de support client
• [ ] OpenAI Realtime API (ou ElevenLabs si lipsync important)
• [ ] LiveKit pour le transport WebRTC
• [ ] Tool use (l'agent peut faire des actions, pas juste parler)
• [ ] Démo web accessible publiquement

Durée : 5 semaines.

Phase 5 — Certification cloud + LinkedIn intensif (semaines 23-26)

Parallèle au Phase 4 ou juste après :

• [ ] GCP Generative AI Leader (4 sem, ~150-200€) — voir 12-certifications.md
• [ ] LinkedIn posts 2× / sem pendant 4 semaines (build audience)
• [ ] Update profil Malt avec les 3 projets
• [ ] Inscription Crème de la Crème
• [ ] Cold outreach : 5 CTO/jour sur LinkedIn dans la verticale

Durée : 4 semaines (concurrentes avec autres phases).

Phase 6 — Première mission (semaines 27-32+)

• [ ] Première mission décrochée (TJM 600-800€ — accepte sous-payé pour seed le track record)
• [ ] Livrer impeccable
• [ ] Demander recommandation LinkedIn + témoignage Malt
• [ ] Augmenter TJM de 20% pour la 2ème mission
• [ ] Spécialiser sur la verticale au fil des missions

Durée : ouvert. Objectif : 3 missions sur 6 mois = positionnement clair, TJM 1000€+.

---

Discipline rules

1. 12-15h/sem minimum, sinon le timeline glisse. Tracker hebdo.
2. Code AVANT lecture quand possible — apprendre par practice > apprendre par théorie pure.
3. 1 post LinkedIn / semaine minimum dès semaine 2 (même petit — "learning X today").
4. Pas de "tutorial hell" — chaque cours doit produire un output (script, repo, post).
5. Claude (moi) en pair-programming : tu codes en partageant ton écran, je guide. JAMAIS "code-moi tout".
6. Pas de switch de stack en cours de route. Tu choisis ta verticale en semaine 1, tu t'y tiens 6 mois minimum.

---

Anti-patterns à éviter

• ❌ Faire 10 cours sans coder
• ❌ Coder 10 projets sans rien finir
• ❌ Tutoriels Colab notebooks → portfolio (ça vaut zéro en 2026)
• ❌ Postuler avant phase 2 (RAG prod-grade déployé)
• ❌ Cacher Dravos parce que "fait avec Claude" → AU CONTRAIRE, mets-le en avant. C'est de l'architecture/infra/produit, c'est ton plus gros asset
• ❌ Vouloir devenir Python expert. Reste TypeScript-first, ajoute Python juste pour LangGraph/data
• ❌ Te disperser sur la verticale. Une seule. Pendant 6 mois minimum.

---

Métriques de suivi (tracker hebdo dans _notes/weekly-log.md)

• Heures travaillées AI cette semaine
• Cours avancés (%)
• Projets : lignes commitées
• LinkedIn : posts publiés / impressions / connexions
• Outreach : CTO contactés / réponses
• TJM cible vs actuel

---

🧱 Le socle technique qui doit infuser TOUT ton portfolio

Tes 3 projets (RAG, agentic+MCP, voice) appellent tous un LLM. Le marché ne te paie pas pour « appeler un LLM » — n'importe qui le fait en 3 lignes. Il te paie parce que ton code tient en prod. Voici le standard senior que chaque pièce doit démontrer (c'est aussi ce qu'on cherche à casser en entretien technique).

Modèle & paramètres (canon Anthropic 2026, à ne jamais te tromper en entretien) :

• Flagship : claude-opus-4-8 (Opus 4.8), 5 $ / 25 $ par M tokens (input/output), contexte 1M. Milieu : claude-sonnet-4-6. Économique : claude-haiku-4-5 (1 $ / 5 $).
• Thinking : thinking={"type": "adaptive"} + output_config={"effort": "low|medium|high|max"}. Le vieux budget_tokens est supprimé sur 4.7/4.8 (renvoie un HTTP 400). Si un recruteur te parle de « thinking budget », tu réponds « adaptive thinking + effort ».
• Sorties structurées : client.messages.parse() avec un schéma Pydantic, pas du XML/JSON prompté à la main.

Les 7 réflexes prod qu'un senior attend dans ton code (et qui transforment un notebook en pièce de portfolio) :

import asyncio
from anthropic import AsyncAnthropic, APITimeoutError, RateLimitError, OverloadedError

client = AsyncAnthropic(max_retries=4)  # 1. retries SDK + backoff exponentiel intégré

SYSTEM = [  # 2. prompt caching sur le préfixe stable (system + tools) → ~90% moins cher en lecture
    {"type": "text", "text": SYSTEM_PROMPT, "cache_control": {"type": "ephemeral"}},
]

async def ask(question: str) -> str:
    try:
        # 3. streaming pour les grosses sorties (évite les timeouts HTTP du SDK > ~16k tokens)
        async with client.messages.stream(
            model="claude-opus-4-8",
            max_tokens=16000,
            system=SYSTEM,
            thinking={"type": "adaptive"},          # 4. adaptive, jamais budget_tokens
            messages=[{"role": "user", "content": question}],
            timeout=60,                              # 5. timeout par appel
        ) as stream:
            msg = await stream.get_final_message()
        log.info("cost", usage=msg.usage)            # 6. log resp.usage → coût/query
        return msg.content[0].text
    except (RateLimitError, OverloadedError, APITimeoutError) as e:
        # 7. exceptions typées (jamais de string-matching sur le message d'erreur)
        raise

# parallélisme des tool calls indépendants
results = await asyncio.gather(*(ask(q) for q in questions))

Si une pièce de portfolio te montre en train d'appeler messages.create() en synchrone, sans retries, sans timeout, sans cache, sans log d'usage → c'est un notebook, pas un asset. La différence de TJM est exactement là.

---

🏋️ Exercices

Ces exercices ne sont pas « change cette constante ». Chacun est une objection d'acheteur que tu dois pouvoir tuer en entretien. Fais-les dans l'ordre — chacun s'appuie sur le précédent.

Exercice 1 — Défends ta timeline contre un CTO sceptique (le plus important)

Objectif : transformer la timeline ci-dessus en argumentaire chiffré que tu peux soutenir sous feu.

Écris une note d'une page qui répond à : « Pourquoi 600-800€ et pas 1400€ tout de suite, avec 7 ans d'XP ? ». Tu dois citer (a) la Loi 1 (ancienneté perçue en IA), (b) au moins 2 baromètres FR 2026 réels avec leur fourchette, (c) le mécanisme preuve/heure. Puis l'inverse : « Pourquoi pas 400€ comme un junior ? » — défends ton plancher avec l'intersection rare (Loi 2).

Indice/Solution : le piège est de défendre un chiffre absolu. Défends une trajectoire et son moteur (preuves vérifiables accumulées), pas un nombre. Si tu ne peux pas nommer ce qui fait passer de 800 à 1100, tu n'as pas compris ta propre roadmap.

Exercice 2 — Le naive RAG prod-grade en 50 lignes (et son coût)

Objectif : passer du « ça marche sur mon laptop » au « je connais mon coût/query au centime ».

Pars du naive RAG de Phase 1. Ajoute : AsyncAnthropic avec max_retries, thinking={"type": "adaptive"}, prompt caching sur le system prompt, et un log de resp.usage à chaque requête. Calcule le coût/query réel sur 100 questions avec claude-opus-4-8, puis re-mesure en basculant le LLM final sur claude-haiku-4-5.

Indice/Solution : instrumente d'abord (usage.input_tokens, output_tokens, cache_read_input_tokens), mesure ensuite. Le cache ne « hit » que si le préfixe est byte-identique d'une requête à l'autre — un datetime.now() dans le system prompt invalide tout silencieusement. Vérifie cache_read_input_tokens > 0 ou tu paies plein pot sans le savoir.

Exercice 3 — Casse-le, puis répare-le

Objectif : prouver que ta pièce tient « au 1er edge case », l'objection #4 du tableau CTO.

Sur ton RAG de l'exercice 2, provoque délibérément 4 pannes et gère-les proprement : (1) rate limit (429) en bombardant l'API — vérifie que le retry SDK absorbe ; (2) un OverloadedError (529) simulé ; (3) une question hors-corpus → le système doit dire « je ne sais pas », pas halluciner ; (4) une sortie tronquée (stop_reason == "max_tokens") → relance avec un max_tokens plus large ou en streaming.

Indice/Solution : branche sur les exceptions typées (RateLimitError, OverloadedError) et sur stop_reason, jamais sur le texte de l'erreur. Le cas (3) ne se règle pas dans le code mais dans le prompt + un seuil de similarité minimal sur le retrieval : si le meilleur chunk est sous le seuil, tu n'appelles même pas le LLM.

Exercice 4 — L'eval qui défend le chiffre

Objectif : ne plus dire « mon RAG est bon » mais « faithfulness 0.92, context_precision 0.88, p95 1.4s, 0.011€/query ».

Branche Ragas (faithfulness, answer_relevancy, context_precision) sur un jeu de 30 questions à vérité-terrain. Ajoute l'observabilité (LangSmith ou OpenTelemetry). Mets les 4 métriques + p95 latence + coût/query dans le README. Puis : améliore une métrique de 10 points (hybrid search ou rerank) et montre le before/after.

Indice/Solution : une métrique sans baseline ne vaut rien — capture le before AVANT d'optimiser. Le piège classique : optimiser le recall et dégrader la latence/coût sans le voir. Tu dois pouvoir défendre le trade-off, pas juste le gain.

Exercice 5 — Le MCP server qu'un autre dev peut brancher

Objectif : tuer l'objection « peut-il intégrer dans NOTRE stack ? » (Phase 3).

Écris un MCP server custom (3-5 tools) exposable à Claude Desktop / Cursor. Contrainte senior : chaque tool a un input_schema strict, gère ses erreurs (renvoie is_error: true avec un message exploitable, ne crash pas), et les actions destructrices/irréversibles sont identifiables pour un gating côté harness. Documente le branchement en 5 lignes pour un dev externe.

Indice/Solution : la question piège — « bash tool ou tools dédiés ? ». Réponse senior : bash pour la largeur, tools dédiés dès qu'il faut gater, auditer, rendre ou paralléliser une action (un send_email se gate, un bash -c "curl ..." non). Un tool dont la description ne dit pas quand l'appeler sous-déclenche sur les modèles récents.

Exercice 6 — La revue adversariale de Dravos (boss final)

Objectif : Phase 0a — être fluent à 100% et survivre à un entretien hostile sur ton plus gros asset.

Fais-toi mock-interviewer (par Claude ou un pair) sur l'architecture de Dravos pendant 45 min, en mode hostile : « pourquoi Temporal et pas Celery ? », « comment tu gères un agent qui boucle à l'infini ? », « ton sandbox, il isole vraiment ? », « c'est fait avec Claude Code, donc qu'est-ce que TU as conçu ? ». Note chaque question où tu hésites > 5s.

Indice/Solution : le mot « fait avec Claude Code » est un piège de perception (Loi 1). Ta défense n'est pas « j'ai tout codé seul » mais « j'ai conçu l'architecture, choisi Temporal pour la durabilité des workflows longs, et je peux walker n'importe quel module au tableau ». Si tu ne peux pas dessiner le state machine d'un agent sans regarder le code, tu n'as pas fini la Phase 0a.

---

🎤 En entretien

• « Avec 7 ans d'XP, pourquoi tu démarres à 800€ ? » → Parce que le marché price l'ancienneté perçue en IA, pas l'ancienneté totale ; je démarre ce compteur à ~1 an et ma trajectoire est gouvernée par les preuves vérifiables que j'accumule, pas par mon CV.
• « Comment tu contrôles le coût d'un système LLM en prod ? » → Je log resp.usage à chaque appel (input/output/cache tokens), je mets le prompt caching sur le préfixe stable (system+tools, ~0.1× en lecture), et je route les tâches simples vers un modèle moins cher (claude-haiku-4-5) plutôt que tout sur le flagship.
• « On veut du "extended thinking" avec un budget de tokens, tu fais comment ? » → Sur Opus 4.7/4.8 le budget_tokens est supprimé (HTTP 400) ; j'utilise l'adaptive thinking (thinking={"type": "adaptive"}) et je règle la profondeur via output_config.effort (low→max). Le concept de budget fixe est remplacé par l'adaptive.
• « Ton RAG renvoie une réponse fausse avec assurance — c'est quoi ta première hypothèse ? » → Le retrieval, pas le LLM : je regarde si les bons chunks remontent (context_precision/recall@k). Si le top chunk est sous mon seuil de similarité, le système doit répondre « je ne sais pas » au lieu d'appeler le LLM — l'hallucination vient presque toujours d'un mauvais contexte injecté avec confiance.

---

Mise à jour : 2026-06-16