Glossaire du développement AI-native : agentic coding, vibe coding & 16 autres termes définis

Le vocabulaire du développement AI-native évolue plus vite que les dictionnaires. De nouveaux termes — agentic coding, vibe coding, MCP, context engineering, subagents — émergent sur X, sont livrés dans une CLI, puis absorbés dans le quotidien des équipes, le tout en l'espace d'un trimestre. Cette page est la référence canonique : chaque terme reçoit d'abord une définition précise et citables, les faits d'origine que la plupart des glossaires ignorent, et une correspondance avec la place de la compétence dans le modèle de développeur AI-native à 7 niveaux — du L1 Développeur assisté par chat au L7 Créateur universel IA.

Chaque entrée se termine par la même question honnête : à quel niveau cela vous situe-t-il ? Une fois la lecture terminée, passez le quiz de 3 minutes et découvrez-le.

Aller directement à un terme

Terme	Correspond à	Terme	Correspond à
Développeur AI-native	L1–L7	Evals	L6
Agentic coding	L3	Worktrees	L5+
Agentic engineering	L4–L5	Context engineering	L4–L6
Vibe coding	Hors échelle	Spec-driven development	L4–L6
Développement assisté par IA	L1–L7	Agent de codage autonome	L3→L5
MCP	L5–L6	Prompt engineering	L1–L2
Orchestration d'agents	L5	Modèle de maturité du codage IA	le modèle
Subagents	L5+	Model routing	L5–L6
Plan-before-code	L3–L4	Verification harness	L4–L5

---

Développeur AI-native

Un développeur AI-native est un développeur dont le flux de travail par défaut consiste à diriger des systèmes IA pour planifier, écrire, tester et livrer du code, plutôt que de taper la majorité des lignes à la main. Cela se mesure par les habitudes d'autonomie et de vérification — pas par le nombre d'outils IA installés.

Aujourd'hui, presque tous les développeurs « utilisent l'IA ». Ce n'est pas la même chose. Être AI-native est une posture, pas un arsenal d'outils : l'IA est votre mécanisme de production principal, et votre rôle évolue vers la direction, la relecture et la vérification. La question déterminante n'est pas utilisez-vous un assistant IA ? — c'est jusqu'où déléguez-vous, et comment vérifiez-vous le résultat ?

C'est précisément ce trait que le modèle de développeur AI-native à 7 niveaux évalue, du L1 Développeur assisté par chat (l'« Artisan à l'ancienne » qui copie-colle depuis un onglet de chat) au L7 Créateur universel IA (une personne qui pilote un cycle produit complet avec des agents). Votre position dépend de l'autonomie et de la vérification, pas des impressions.

À quel niveau cela vous situe-t-il ? Passez le quiz →

Agentic coding

L'agentic coding est une approche de développement où des agents IA autonomes planifient, écrivent, exécutent, testent et modifient du code sur plusieurs étapes avec une intervention humaine minimale, en utilisant des outils — shell, modifications de fichiers, runners de tests — au sein d'une boucle de rétroaction jusqu'à l'accomplissement de la tâche.

Le mot clé est boucle. L'autocomplétion en conversation unique vous donne un extrait de code et s'arrête ; un agent de codage agentique prend en charge la tâche dans son intégralité. Il lit le dépôt, établit un plan, modifie des fichiers, lance les tests, lit les échecs, et recommence — itérant sur une longue trajectoire plutôt que de répondre à une seule invite. Google Cloud le définit comme une approche de développement logiciel où des agents IA autonomes planifient, écrivent, testent et modifient du code avec une intervention humaine minimale ; IBM décrit les agents de codage sous-jacents comme des systèmes IA qui combinent le raisonnement d'un LLM avec l'accès à des outils de codage pour agir sur plusieurs étapes.

Sur l'échelle, l'agentic coding est la marque de fabrique du L3, le Développeur agentique (« The Agentic Native ») — où l'agent écrit le code routinier, vous planifiez avant de coder, et vous ne prenez pas sa parole pour argent comptant. Approfondissez dans le pilier agentic coding ou consultez le niveau directement à L3 →.

À quel niveau cela vous situe-t-il ? Passez le quiz →

Agentic engineering

L'agentic engineering est la discipline professionnelle qui consiste à orchestrer des agents IA de codage comme des multiplicateurs de force, tandis que l'humain conserve la responsabilité de l'architecture, de la qualité et de la vérification. Les agents font la majorité de la frappe ; l'ingénieur dirige, contraint et valide.

Si l'agentic coding est la technique, l'agentic engineering en est la rigueur. Selon MindStudio, c'est la pratique consistant à orchestrer des agents IA de codage pour qu'ils réalisent l'essentiel du codage tandis que l'humain conserve la maîtrise de l'architecture, de la qualité du code et du jugement d'ingénierie — présenté comme le successeur discipliné du vibe coding pour 2026. L'accent est mis sur les specs, les evals, la revue et la reproductibilité plutôt que sur l'« accepter et espérer ».

Cela correspond à la bande L4–L5 — le Directeur et l'Orchestrateur — où vous cessez de taper du code routinier pour construire le système qui le produit. Voyez comment le vibe coding et l'agentic engineering divergent dans vibe coding vs agentic coding, ou parcourez les niveaux.

À quel niveau cela vous situe-t-il ? Passez le quiz →

Vibe coding

Le vibe coding consiste à construire des logiciels en soumettant des invites à une IA et en acceptant son résultat sans examiner le code. Andrej Karpathy a forgé le terme le 2 février 2025, en décrivant le fait de se laisser totalement emporter par les vibes et d'oublier que le code existe — accepter les modifications de l'IA sans lire les diffs.

Simon Willison l'a affiné en un test opérationnel : le vibe coding, c'est « construire des logiciels avec un LLM sans examiner le code qu'il écrit ». Son corollaire est la partie qui préoccupe les développeurs seniors — si vous examinez, testez et pouvez expliquer le code, « c'est du développement logiciel », pas du vibe coding. Cette ligne est tout l'enjeu. Le vibe coding est idéal pour les prototypes jetables et les expériences de week-end ; c'est une source de risques dès lors que la chose doit tourner en production sans surveillance.

Critiquement, le vibe coding se situe hors de l'échelle d'ingénieur L1–L7. Il produit l'archétype du Vibe Builder : un créateur no-code/IA qui livre de vrais produits avec des outils de création d'applications IA sans écrire de code traditionnel — AI-native dès le premier jour, mais une espèce différente de l'ingénieur qui gravit l'échelle de maturité. Ce n'est pas une rétrogradation ; c'est un autre jeu avec son propre super-pouvoir (la vitesse) et son propre plafond. Plus de détails dans vibe coding et la comparaison directe vibe coding vs agentic coding.

À quel niveau cela vous situe-t-il ? Passez le quiz →

Développement assisté par IA

Le développement assisté par IA désigne tout flux de travail dans lequel des outils IA — autocomplétion, chat ou agents — aident à écrire ou modifier du code tandis qu'un humain reste dans la boucle pour examiner et décider. C'est le grand parapluie qui couvre tout, de L1 à L7.

Considérez-le comme l'ensemble englobant. Le vibe coding et l'agentic coding s'inscrivent tous deux dans le développement assisté par IA ; ce qui les distingue, c'est le degré d'autonomie accordé et la façon dont vous vérifiez le résultat. Accordez peu et relisez tout à la main, et vous êtes un délégant en bas de l'échelle. Accordez beaucoup mais câblez un verification harness, et vous faites de l'agentic engineering discipliné. Le terme lui-même est délibérément large — c'est précisément pourquoi un modèle à niveaux est utile pour se situer dedans.

Le modèle à 7 niveaux est la carte qui transforme ce parapluie en un spectre sur lequel vous pouvez vous positionner.

À quel niveau cela vous situe-t-il ? Passez le quiz →

MCP (Model Context Protocol)

MCP (Model Context Protocol) est un standard ouvert qui permet aux modèles IA de se connecter à des outils externes et des sources de données via une interface universelle unique, au lieu d'intégrations spécifiques à chaque outil. Anthropic l'a introduit et publié en open source le 25 novembre 2024 (version de spec 2024-11-05), avec des SDK Python et TypeScript.

L'analogie qui s'impose est « l'USB-C des outils IA » : un seul protocole, et tout client conforme peut parler à tout serveur conforme — vos docs, votre base de données, votre gestionnaire de tickets, votre shell. Avant MCP, chaque intégration était une solution sur mesure ; après lui, la portée de l'agent devient un écosystème de plugins. L'adoption s'est largement répandue dans l'industrie au cours de 2025–2026, et vous pouvez lire la source primaire dans l'annonce d'Anthropic.

Connecter un serveur MCP clé en main est quelque chose que la plupart des développeurs assistés par IA peuvent faire tôt. Mais gouverner MCP au sein d'une équipe — décider ce que les agents sont autorisés à atteindre et concevoir des serveurs réutilisables — est un signal de niveau L5–L6 Méthodologue. Voir L6 → et l'entrée connexe sur l'orchestration d'agents.

À quel niveau cela vous situe-t-il ? Passez le quiz →

Orchestration d'agents

L'orchestration d'agents consiste à coordonner plusieurs agents IA — affecter des tâches, séquencer les étapes, gérer l'état partagé et fusionner les résultats — afin qu'une équipe d'agents accomplisse un travail qu'un seul agent ne pourrait pas réaliser de manière fiable seul.

La forme dominante est le pattern orchestrateur-travailleur (manager-travailleur) : un agent planifie et délègue tandis que des agents travailleurs délimités exécutent et rendent compte. Selon la documentation de Claude Code, dans ce pattern l'orchestrateur possède le plan et chaque travailleur gère une tâche délimitée — la structure qui rend le travail multi-agents gérable plutôt que chaotique.

C'est le trait définitoire du L5, l'Architecte d'ingénierie IA (« The Orchestrator ») — le niveau où vous concevez la pile d'agents plutôt que de simplement piloter un seul agent. Voir L5 →, puis les éléments constitutifs : subagents et worktrees.

À quel niveau cela vous situe-t-il ? Passez le quiz →

Subagents

Les subagents sont des agents travailleurs isolés auxquels un agent principal délègue des tâches, chacun s'exécutant avec son propre contexte, accès aux outils et permissions, et retournant un seul résumé — gardant le contexte de l'agent principal propre et le travail parallélisable.

Les subagents sont ce qui permet à l'orchestration de rester sensée. Au lieu d'une fenêtre de contexte surchargée gérant tout, l'agent principal lance des travailleurs délimités, chacun avec une ardoise vierge, et récupère un résultat ordonné. Selon la documentation de Claude Code, chaque subagent s'exécute avec son propre contexte, ses outils et ses permissions — et ne peut pas lancer d'autres subagents, de sorte que l'imbrication est bornée par conception. Cette limite est une fonctionnalité : elle prévient les arbres d'agents incontrôlables.

L'utilisation régulière de subagents est un signal comportemental L5+ — vous êtes passé du pilotage d'un seul agent à la gestion d'une petite équipe. Voir L5 → et le pattern plus large à orchestration d'agents.

À quel niveau cela vous situe-t-il ? Passez le quiz →

Plan-before-code

Le plan-before-code est une discipline d'agentic coding où l'agent (ou l'humain) produit un plan explicite et obtient son approbation avant d'écrire le moindre code — de sorte que l'intention est vérifiée en amont et que l'étape d'implémentation reste délimitée et vérifiable.

C'est une police d'assurance bon marché. Quelques minutes passées à confirmer « voici ce que je vais faire et pourquoi » évitent le scénario coûteux où un agent modifie avec confiance vingt fichiers dans la mauvaise direction. Cela consomme aussi moins de tokens et produit des diffs sur lesquels on peut réellement raisonner. Le plan-before-code est l'habitude passerelle qui mène naturellement au spec-driven development.

C'est une habitude de maturité L3–L4 — le moment où vous cessez de laisser les agents s'exécuter librement et où vous commencez à les conditionner à un plan approuvé.

À quel niveau cela vous situe-t-il ? Passez le quiz →

Verification harness

Un verification harness est l'ensemble des vérifications automatisées — tests, linters, vérifications de types, scripts de build et d'exécution — câblés de sorte qu'un agent IA puisse vérifier son propre travail en boucle et s'autocorriger, sans qu'un humain lise chaque diff.

C'est la chose unique qui rend l'agentic coding haute autonomie (« YOLO ») sûr plutôt que téméraire. Un agent doté d'un harness solide peut s'emballer en toute sécurité — essayer une modification, lancer les vérifications, lire les échecs, corriger, recommencer — parce que les vérifications attrapent ses erreurs avant vous. Un agent sans harness n'est que du risque non examiné avançant à grande vitesse. Le harness est ce qui convertit la confiance en système plutôt qu'en espoir.

La construction de harnesses réutilisables est la ligne de démarcation L4–L5 — elle sépare « je relis chaque modification » de « je fais confiance à la boucle et je relis le résultat ». Voir les niveaux →, puis associez cela aux evals.

À quel niveau cela vous situe-t-il ? Passez le quiz →

Evals

Les evals sont des tests systématiques qui mesurent si un modèle IA ou un agent produit des sorties correctes et fiables. Pour les agents de codage, les evals vérifient si l'agent planifie, appelle des outils et accomplit des tâches multi-étapes correctement sur toute une trajectoire — pas seulement si la réponse finale semble juste.

Il existe deux formes principales, selon Confident AI : les evals basés sur le code (assertions automatisées de style CI) et le LLM-as-a-judge. Pour le travail de codage, la trajectoire compte car une exécution couvre de nombreuses étapes — un agent peut produire le bon fichier pour de mauvaises raisons, ou emprunter une voie dangereuse vers un test réussi. Les evals détectent cela. Ils marquent la différence entre « ça a marché une fois » et « ça marche de manière fiable ».

Écrire et maintenir des evals est un signal de Méthodologue L6 — vous n'utilisez plus seulement des agents, vous mesurez et certifiez leur comportement. Voir L6 → et son équivalent, le verification harness.

À quel niveau cela vous situe-t-il ? Passez le quiz →

Worktrees

Les worktrees Git sont des répertoires de travail séparés qui partagent l'historique d'un même dépôt, permettant à plusieurs agents IA de travailler chacun sur une branche ou un checkout isolé en parallèle — sans écraser les fichiers des autres.

C'est le mécanisme standard pour exécuter plusieurs sessions Claude Code sur un même codebase simultanément. Selon la documentation de Claude Code, un worktree est un répertoire de travail séparé avec sa propre branche partageant le même historique de dépôt, ce qui permet à plusieurs agents de travailler en parallèle sur des checkouts isolés. En pratique, on associe les worktrees à l'isolation des ports et des bases de données afin que les agents parallèles n'entrent pas en collision en dehors du système de fichiers non plus.

Les workflows d'agents parallèles dans des worktrees sont un trait L5+ — le Directeur L4 fait déjà fonctionner plusieurs agents de cette façon, et l'Orchestrateur L5 le systématise. Voir orchestration d'agents et L5 →.

À quel niveau cela vous situe-t-il ? Passez le quiz →

Context engineering

Le context engineering est, selon la formulation d'Andrej Karpathy de juin 2025, « l'art et la science délicats de remplir la fenêtre de contexte avec exactement les bonnes informations pour l'étape suivante. » C'est la discipline qui consiste à concevoir tout ce qu'un LLM voit : instructions, documents récupérés, sorties d'outils, mémoire et état.

Karpathy a consacré ce terme en remplacement du « prompt engineering » en juin 2025, et Anthropic a formalisé le concept en septembre 2025. Ce recadrage est important : dans les systèmes d'agents en production, la formulation d'une invite donnée ne représente qu'une petite partie de ce qui détermine la qualité des sorties. Comme le souligne Glean, le prompt engineering est un sous-ensemble du context engineering — le contexte complet inclut aussi l'historique de la conversation, les documents récupérés, les sorties des outils et l'état de l'agent. L'écart de qualité entre les utilisateurs d'IA aujourd'hui, c'est le contexte, pas des mots magiques.

Le context engineering délibéré est un signal L4–L6 — c'est ce que font les personnes qui soignent leurs fichiers CLAUDE.md, conçoivent la récupération d'information et gèrent consciemment le budget de la fenêtre de contexte. Contraster avec son sous-ensemble, le prompt engineering, et voir les niveaux →.

À quel niveau cela vous situe-t-il ? Passez le quiz →

Spec-driven development

Le spec-driven development est une méthodologie qui fait d'une spécification écrite la source de vérité que les agents IA utilisent pour générer, tester et valider du code. Vous écrivez d'abord la spec, puis un plan, puis de petites tâches testables, puis l'implémentation.

Selon GitHub, la spécification devient un contrat décrivant le comportement attendu du code — la source de vérité que les outils et les agents IA utilisent pour générer, tester et valider du code. GitHub a annoncé et publié en open source Spec Kit (licence MIT) le 2 septembre 2025, avec le flux central Spec → Plan → Tasks → Implement, explicitement positionné comme une alternative répétable et disciplinée au vibe coding ad hoc. C'est le plan-before-code poussé jusqu'à sa conclusion logique.

Les workflows spec-driven sont un marqueur de maturité L4–L6. Ils s'appuient sur le plan-before-code et sont au cœur de la façon dont les Directeurs et les Méthodologues livrent. Voir les niveaux →.

À quel niveau cela vous situe-t-il ? Passez le quiz →

Agent de codage autonome

Un agent de codage autonome est un système IA qui prend un objectif et planifie, modifie des fichiers, exécute des commandes et des tests, et itère jusqu'à l'accomplissement de la tâche — opérant sur une longue trajectoire multi-étapes plutôt que de répondre à une seule invite.

Les agents CLI comme Claude Code en sont l'exemple canonique. La nuance importante est que l'autonomie est un spectre, pas un interrupteur : la distance jusqu'où vous laissez un agent s'exécuter sans surveillance (« mode YOLO ») est conditionnée par deux choses — votre verification harness et les permissions que vous lui accordez. Harness solide plus permissions strictes équivaut à une autonomie sûre. Harness faible plus permissions larges équivaut à un après-midi catastrophique.

Apprendre à faire confiance aux agents autonomes sans casser la production est la progression L3 → L5 elle-même : de « l'agent écrit le code routinier » à « l'agent gère des cycles multi-tickets de bout en bout ». Voir les niveaux →.

À quel niveau cela vous situe-t-il ? Passez le quiz →

Prompt engineering

Le prompt engineering est la pratique qui consiste à formuler les instructions textuelles données à un LLM — formulation, exemples, rôle et format de sortie — pour orienter le modèle vers un résultat souhaité en un seul tour.

Cela compte encore ; des instructions claires l'emportent toujours sur des instructions négligées. Mais le domaine l'a recadré comme une composante d'une discipline plus large. Dans les systèmes d'agents en production, l'invite ne représente qu'une petite fraction du contexte total, qui inclut aussi l'historique, les documents récupérés, les sorties des outils et l'état — c'est pourquoi le context engineering est devenu le cadre le plus utile.

Le prompt engineering est un pilier L1–L2 qui évolue vers le context engineering vers L4. C'est là où la plupart des gens commencent ; ce n'est pas là que se trouve le plafond.

À quel niveau cela vous situe-t-il ? Passez le quiz →

Modèle de maturité du codage IA

Un modèle de maturité du codage IA est un cadre à niveaux qui évalue dans quelle mesure un développeur ou une équipe est AI-native — par les comportements d'autonomie et de vérification, pas par le nombre d'outils. Le modèle de développeur AI-native à 7 niveaux de ProCoders (L1 Assisté par chat → L7 Créateur universel IA) en est un exemple ; les 8 étapes du workflow agentique de Steve Yegge en est un autre.

Les modèles de maturité donnent à un domaine en rapide évolution un vocabulaire partagé pour le gradient de confiance — la pente allant de « l'IA complète une ligne » à « j'ai construit mon propre orchestrateur ». Les 8 niveaux de Yegge décrivent ce même gradient, d'une utilisation quasi nulle de l'IA jusqu'à la construction de son propre orchestrateur, avec la rupture critique aux étapes 5–6 où un seul agent synchrone cède la place à plusieurs agents parallèles (selon le résumé d'Augment Code). Le cadre par niveaux est ce qui permet aux équipes de parler de direction plutôt que simplement d'outils.

L'exemple canonique sur ce site est le modèle — le modèle de développeur AI-native à 7 niveaux nommé, avec des personas et des signaux comportementaux concrets pour chaque échelon. Le moyen le plus rapide de l'utiliser est le quiz.

À quel niveau cela vous situe-t-il ? Passez le quiz →

Model routing

Le model routing consiste à choisir automatiquement quel modèle IA ou fournisseur traite chaque requête en fonction du coût, de la latence, des capacités et de la disponibilité — envoyant les tâches simples aux modèles bon marché et les tâches difficiles aux modèles frontière, avec des solutions de repli.

C'est un levier de coût et de fiabilité, et l'écart est suffisamment large pour être significatif : selon OpenRouter, le coût par token entre les modèles frontière et les modèles moins chers peut différer d'environ 10× à 50×, et des plateformes comme OpenRouter exposent des contrôles de routage et des plafonds de prix. Routez intelligemment une flotte d'agents et vous réservez les modèles frontière coûteux aux travaux qui en ont vraiment besoin, tandis que les modèles moins chers absorbent le volume facile.

Router des modèles à travers une flotte d'agents — et définir la politique correspondante — est un signal d'architecte L5–L6 ; l'Orchestrateur L5 possède la politique de model routing à travers les agents de l'équipe. Voir L5 →.

À quel niveau cela vous situe-t-il ? Passez le quiz →

---

Comment ces termes se mappent sur l'échelle

Les définitions ne sont que la moitié de l'histoire. Si ce glossaire associe chaque terme à un niveau, c'est parce que le même mot signifie des choses différentes selon la maturité. « Utiliser MCP » est un signal précoce ; « gouverner MCP » en est un avancé. « Lancer un agent » correspond à L3 ; « orchestrer une flotte dans des worktrees » correspond à L5. Voici la carte condensée :

Niveau	Persona	Termes du glossaire qui le signalent
L1 Assisté par chat	Old-School Artisan	prompt engineering
L2 Junior assisté par IA	Delegator	prompt engineering, développement assisté par IA
L3 Développeur agentique	Agentic Native	agentic coding, plan-before-code, agent de codage autonome
L4 Constructeur de systèmes	Director	verification harness, spec-driven development, context engineering
L5 Architecte d'ingénierie	Orchestrator	orchestration d'agents, subagents, worktrees, model routing
L6 Méthodologue	Methodologist	evals, gouvernance MCP, méthodes portables
L7 Créateur universel IA	Creator	cycle complet en solo sur tous les éléments ci-dessus
Hors échelle	Vibe Builder	vibe coding

Cette dernière ligne est la distinction que les glossaires génériques ratent. Le vibe coding n'est pas un échelon bas — c'est une échelle entièrement différente. Le Vibe Builder livre des produits sans code traditionnel ; l'ingénieur L1–L7 gravit l'échelle vers la direction de systèmes qui font le travail. Les deux sont légitimes ; ce ne sont simplement pas le même chemin.

Trouvez votre niveau

Lire des définitions vous dit ce que signifient les mots. Le quiz vous dit où vous vous situez dans le modèle de développeur AI-native à 7 niveaux — en fonction de vos habitudes réelles d'autonomie et de vérification, en environ trois minutes.

Passez le quiz → /quiz