De prompt engineer à agentic AI engineer — les 5 patterns qui m'ont transformé

Un prompt engineer parle au modèle. Un agentic AI engineer construit un système que le modèle orchestre.

J’ai réalisé cette différence il y a quelques mois, en migrant mes workflows quotidiens. Au début, j’envoyais simplement des prompts plus longs, plus structurés, en espérant que le modèle comprendrait mieux. Ça fonctionnait pour des cas simples. Mais dès que la complexité montait—dès qu’il fallait gérer du contexte évolutif, prendre des décisions en cascade, récupérer et transformer des données à la volée—j’ai buté sur un mur. Ce n’était pas une distinction sémantique. C’était un changement de mentalité fondamental. Passer de « comment je demande ? » à « comment le système décide ? » change absolument la façon de penser l’architecture.

Les articles parlent souvent d’une roadmap à 14 étapes pour devenir agentic AI engineer—de Python jusqu’au déploiement, comme s’il y avait une progression linéaire à respecter. Elle est utile, je ne dis pas le contraire. Mais voici le problème : cette roadmap enseigne le quoi. Quels frameworks utiliser. Quels outils maîtriser. Comment passer de LangGraph à la RAG, puis à l’évaluation. Mais elle ne enseigne presque jamais le pourquoi l’architecture réelle importe. Quels patterns déterminent vraiment le succès. Pourquoi certains systèmes cassent en production alors qu’ils semblaient solides en dev.

J’ai compris cette distinction en migrant vers des systèmes plus complexes. Apprendre Langraph, c’est acquérir une compétence. Savoir quand et pourquoi structurer un système avec Langraph, c’est développer un jugement architectural. La vraie transformation n’est pas dans le framework qu’on choisit. Elle est dans la question qu’on se pose avant de choisir. Passer de « quel framework utiliser ? » à « comment construire un système où le modèle décide correctement ? » change absolument la mentalité.

C’est ce décalage qui sépare vraiment le prompt engineer de l’agentic AI engineer. Le premier se demande : « comment je formule bien ma demande ? » Le second se demande : « comment j’architécte un système où la responsabilité de décider est bien distribuée ? Où les données circulent au bon moment ? Où l’IA intervient précisément quand elle doit intervenir ? »

Ces 5 patterns, ce sont eux. Ce sont les leviers architecturaux que la roadmap évoque sans jamais les nommer explicitement. Ce que j’ai découvert, c’est qu’une fois qu’on les reconnaît, on ne peut plus les ignorer. On juge chaque nouvelle architecture à travers leur prisme. On comprend pourquoi certains systèmes marchent vraiment en production, comment corriger les autres.

Les 5 patterns

Pattern 1: Data-Driven Configuration (The Foundation)

Ton agent n’est pas défini dans le code. Il est défini dans des données structurées—YAML, fichiers, configurations. Le système lit ces données à l’exécution, pas au build. C’est la première distinction fondamentale. Tout ce qui pourrait changer sans redéployer devrait vivre dans une donnée, pas gravé dans du code.

Le problème qu’il résout

Avant : tu veux changer la persona de ton agent. Ajouter une instruction système. Affiner son tone. Ajouter un nouveau skill. Tu édites le code source, tu lances le déploiement, tu redémarres le système. Pendant ce temps, le système est offline ou tu exécutes l’ancienne version. Chaque itération devient un cycle complet. Et si tu dois tester trois variations de persona avant de trouver celle qui marche ? Trois redéploiements. Trois redémarrages.

Après : tu changes un fichier YAML. Le système le relit au prochain appel. Zéro downtime. Zéro redéploiement. C’est crucial quand tu as plusieurs agents en production et que tu dois itérer rapidement sur leur comportement sans affecter le reste du système. Les mêmes trois variations ? Trois changements de fichier. Quelques secondes chacun.

Ce que j’ai découvert

J’ai réalisé que mes agents ne devaient jamais avoir de code dur. Zéro. Tout devrait être une donnée—la persona, les instructions systèmes, les skills disponibles, les outils autorisés, même les paramètres comme la température ou les limites de contexte. C’est un changement de perspective radical.

Quand tu fais ça, l’architecture devient soudain vivante. Tu peux expérimenter, itérer, corriger un agent sans toucher à l’infra. Le code devient un moteur générique qui lit et exécute une configuration. Ça veut dire que tu peux deployer une fois et itérer infiniment sur le comportement de ton système. Le couplage entre « ce que l’agent fait » et « comment l’infra fonctionne » disparaît.

C’est un décalage subtle mais profond. Ça force aussi une discipline architecturale : si tu ne peux pas externaliser quelque chose en donnée, c’est peut-être un signal que ton abstraction n’est pas bonne. Ça t’oblige à penser plus clairement et à remettre en question tes assomptions.

C’est pourquoi c’est le pattern fondateur. Les quatre autres patterns découlent de celui-ci. Dès que tu acceptes que tes agents vivent dans des données, tu comprends comment les orchestrer en production, comment évaluer leurs décisions, comment les adapter en temps réel sans redéploiement.

Pattern 2: LIVE Orchestration via Middleware (The Heart)

Maintenant que tu as externalisé la configuration, vient la question qui tue : comment une même configuration gère-t-elle des contextes différents ? Comment un agent s’adapte sans que tu aies à prévoir tous les cas à l’avance ?

La réponse : le middleware n’injecte pas une configuration figée une fois et congelée. Il injecte différentes configurations à chaque tour, en fonction du contexte actuel. La persona change. Les skills disponibles changent. Les outils qu’on autorise changent. Le modèle change même, selon ce qu’on demande. Ce n’est pas un agent qui reste le même d’une invocation à l’autre. C’est un agent qui se reconfigure à chaque appel, en fonction de ce que le contexte exige.

Le problème qu’il résout

Avant : tu définis ton agent une fois. “Voilà, tu as ces 8 skills, ce système prompt, ce modèle.” À chaque exécution, tu passes simplement ta question. Mais ça veut dire que tu dois prévoir d’avance tous les contextes possibles. Tu dois imaginer les cas d’usage les plus exigeants, les outils qu’il faudra peut-être, les limites de tokens, et les backer dans le agent default. Résultat : tu crées un agent généraliste lourd, qui traîne des outils inutiles pour 90 % des requêtes, juste au cas où.

Après : tu crées un middleware qui dit « regardez cette requête. C’est une demande d’analyse de données. Je vais donc charger les skills analytiques, pas les skills de communication. » Ou : « C’est une tâche simple. Je vais utiliser le modèle rapide, moins cher. » Ou encore : « C’est une tâche complexe qui demande du contexte. Je vais ajouter un étape de retrieval avant d’appeler l’agent, et lui injecter le résultat dans ses variables dynamiques. » Chaque décision est programmée dans le middleware, pas gravée dans l’agent.

Ce que j’ai découvert

Le vrai défi n’était pas le modèle. Le modèle fait ce qu’on lui demande. Le vrai défi était l’orchestration—décider quoi injecter, quand, comment. Pendant longtemps, j’ai pensé que le travail se faisait « à l’intérieur » du modèle. Que la qualité sortait de ma capacité à formule un prompt parfait. Mais en réalité, ce qui fait ou casse un système, c’est ce qu’on propose au modèle avant qu’il pense.

C’est une distinction qui change tout. Le middleware devient la zone où vivent les vraies décisions. C’est là qu’on demande : qui a besoin de quel contexte ? Quels outils sont pertinents ? Quel modèle est adapté au budget de cette requête ? Quel est le bon compromis entre qualité et coût ? Chaque réponse est une injection dynamique. Le modèle reçoit un package parfaitement taillé pour sa tâche, pas un fourre-tout générique.

C’est pourquoi c’est « The Heart ». Pattern 1 pose les fondations. Mais Pattern 2 est le cœur battant du système. C’est là où il devient vraiment vivant, vraiment réactif. C’est ce qui fait la différence entre un agent statique et un système qui respire, qui s’adapte, qui prospère dans des contextes changeants sans redéploiement.

Pattern 3: Dynamic Subagent Discovery (Scalability)

Jusqu’à présent, on a parlé de configurer et adapter un seul agent en temps réel. Mais qu’arrive-t-il quand tu dois gérer non plus un, mais une dizaine d’agents ? Une centaine ? La question semble saugrenue au premier abord. Mais en vrai, c’est ce qui sépare un système qui fonctionne de celui qui s’écroule sous son propre poids.

Le problème qu’il résout

Avant : chaque nouvel agent, tu l’enregistres dans le code. Ou dans une configuration gravée. Tu lui donnes un identifiant, tu defines ses rôles, ses outils, tu le branche à l’orchestration centrale. Ajouter un agent c’est une décision architectural. C’est un changement qui demande du testing, de la review, un déploiement. Et si demain quelqu’un veut créer un nouvel agent spécialisé sans passer par le processus complet ? Trop lourd.

Après : tu crées un répertoire, tu y mets la configuration du nouvel agent, et c’est fini. Le système la détecte automatiquement. Pas de redéploiement. Pas de code change. Pas de restart. Le système scanne son dossier « agents », charge chaque configuration, les injecte dans l’orchestration. Nouveau agent ? Il marche tout de suite. Tu veux le retirer ? Tu le supprimes du dossier. Le système s’adapte au prochain appel.

Ce que j’ai découvert

À un moment, j’ai réalisé que créer un nouveau subagent ne devrait pas être une décision d’architecture. Ça devrait être aussi simple que créer un dossier.

C’est un décalage radical. Parce que ça veut dire que ton système n’est plus une configuration figée qu’on pousse en prod une fois par sprint. C’est un réseau vivant d’agents qui peut grandir organiquement. Quelqu’un a une idée pour un nouvel agent spécialisé ? Il crée un dossier, écrit sa configuration, et c’est prêt. Pas de dépendance au planning de release. Pas de cycle d’attente. C’est une forme de modularité que j’avais jamais expérimentée avec une système classique.

Ça force aussi une discipline : chaque agent doit être composable. Il doit pouvoir fonctionner indépendamment de la connaissance des autres agents. Sa configuration doit être auto-suffisante. C’est un peu comme écrire du code découplé—mais à l’échelle de systèmes entiers.

Pattern 1 a décentralisé la configuration des agents. Pattern 2 a rendu l’orchestration dynamique. Pattern 3 en tire la conséquence ultime : si les agents sont des données, et si l’orchestration est vivante, alors ajouter un nouvel agent n’est pas un changement système. C’est juste du contenu qu’on ajoute. Et le système se rebalance automatiquement.

Pattern 4: Per-Call Context Injection (Security & Isolation)

À ce stade, tu as un système flexible, modulaire, qui respire. Mais il y a un piège silencieux qu’on ignore souvent : l’État.

Si ton agent garde en mémoire un état global—qui l’a invoqué, quels contextes il a déjà vus, quelles permissions il a accordées—tu crées instantanément des risques de sécurité cachés. Deux requêtes concurrentes ? Elles peuvent se piler dessus. Un utilisateur accède à un contexte qu’il ne devrait pas ? C’est parce que l’état global l’a laissé passer. Multitenancy devient un cauchemar.

La réponse est radical : l’agent n’a aucun état global. Zéro. Tout ce qui pourrait être contexte—l’utilisateur qui invoque, le scope des données accessibles, les permissions, la collection de contexte, tout—est injecté dans chaque appel à l’agent. L’agent ne « connaît » rien de lui-même. Il est complètement stateless. Il reçoit un package complet au démarrage de la requête, l’exécute, et c’est fini. Le package suivant apporte un contexte complètement différent. Pas de trace, pas de mélange, pas de fuite.

Le problème qu’il résout

Avant : tu relâches un agent en production. Tout marche bien. Trois mois plus tard, tu découvres qu’une utilisatrice a accédé à des données d’un autre utilisateur parce que l’agent gardait en cache un jeton d’accès invalide qui n’avait jamais été réinitialisé. Ou deux requêtes concurrentes ont pollué l’état interne et une a reçu le contexte de l’autre. Tu dois alors retracer tous les accès, vérifier l’intégrité des données, potentiellement avouer une brèche.

Après : tu injectes le contexte complet et actuel dans chaque appel. L’agent ne peut accéder qu’à ce qu’on lui donne. Les deux requêtes concurrentes ? Elles reçoivent des packages différents, aucune interférence possible. Revocation de permission ? Tu changes simplement ce qui est injecté au prochain appel. L’autorisation devient une première classe du système, pas une couche qu’on ajoute par dessus.

Ce que j’ai découvert

Le moment clé : je me suis rendu compte que les agents ne doivent pas « connaître » qui les utilise ou quel contexte ils opèrent. Ça doit être injecté dans chaque appel. Pas de mémoire persistante. Pas de cache. Pas d’état. Chaque invocation est un univers propre, fourni au démarrage, complètement isolé des autres.

Ça change radicalement comment tu penses la sécurité. Ce n’est plus « comment j’ajoute une couche d’authentification? » C’est « comment je garantis que chaque agent ne reçoit que ce qu’il doit recevoir, injecté au moment de l’appel, sans possibilité de débordement? » C’est une posture défensive par défaut, pas une couche ajoutée après. Et ça rend la multitenancy safe d’une façon qui serait quasi impossible autrement.

Pattern 1, 2, et 3 t’ont donné un système flexible et modulaire. Pattern 4 en fait un système sûr. C’est la couche de sécurité architecturale qui rend le système vraiment digne de production. Pas de back door invisibles. Pas de fuite de contexte. Pas de race conditions qui attendent d’exploser en prod.

Pattern 5: Graceful Degradation & Hot Reload (Resilience)

Je construisais un système où des gens éditent les agents en live. Pas en dev. En production. D’autres personnes utilisent le système pendant qu’ils itèrent sur les configurations. Et la première question qui arrive c’est : comment ça ne crash pas?

La réponse que j’ai trouvée c’est une philosophie de résilience qui s’appelle graceful degradation. L’idée est simple : le système ne doit jamais s’arrêter parce que quelqu’un modifie un fichier de configuration. Pas même si cette configuration est malformée. Pas même si elle est incomplète. Le système continue à fonctionner avec la dernière version valide qu’il connaît. La nouvelle version est testée, validée. Si elle est bonne, elle est chargée. Si elle est mauvaise, elle est ignorée, et un log l’enregistre. Mais le service reste vivant.

Le problème qu’il résout

Avant : tu édites le fichier de configuration d’un agent. Il y a une typo YAML. Tu l’enregistres. Le système essaie de le recharger. Le parseur casse. Exception. Et boom—l’agent ne démarre plus pour personne. Tout le service s’écroule. Ou pire encore, tu charges une nouvelle configuration qui est incomplète, qui oublie un champ obligatoire. Aucune validation. Aucune fallback. Le système commence à se comporter de façon imprévisible. Les autres requêtes qui arrivent reçoivent des réponses bizarres. C’est un cauchemar en production.

Après : tu édites la configuration. Il y a une erreur. Le système détecte l’erreur au parse, la loggue, et continue à utiliser la configuration précédente qui marche. Zéro downtime. Zéro impact utilisateur. L’éditeur de config voit l’erreur dans les logs et corrège en deux secondes. C’est un processus d’apprentissage—pas une catastrophe. Tout le monde reste tranquille. Le système fonctionne en arrière-plan.

Ce que j’ai découvert

La résilience n’est pas optionnelle. C’est une première classe du système. Ça veut dire que chaque point de variation—chaque fichier qui pourrait changer, chaque donnée injectée—doit avoir deux choses : une validation au chargement et un fallback si ça échoue.

Ça force une mentalité de robustesse. Tu ne peux pas supposer que la configuration est valide. Tu dois la valider explicitement. Tu ne peux pas supposer qu’un nouveau champ existe toujours. Tu dois prévoir qu’il ne soit pas là, et tu dois avoir une valeur par défaut. C’est un peu comme programmer défensivement, mais à grande échelle.

Pattern 1 a décentralisé la configuration. Pattern 2 l’a rendue vivante. Pattern 3 l’a rendue modulaire. Pattern 4 l’a rendue sûre. Pattern 5 la rend indestructible. C’est le pattern qui transforme un système fragile—qui casse dès qu’il y a une petite erreur—en un système qui prospère même sous pression, même quand les gens font des changements en production.

Ces 5 patterns dans le contexte du roadmap

Je sais ce que tu penses. Tu as lu une roadmap à 14 étapes sur Medium, ou ailleurs, qui dit qu’il faut d’abord maîtriser Python, puis LangGraph, puis RAG, puis l’évaluation, et enfin la prod. Et tu te demandes : où rentrent ces 5 patterns dans cette progression?

La réponse est nuancée. Le roadmap à 14 étapes enseigne le quoi. Quoi apprendre. Par quel ordre. Quels frameworks connaître. C’est utile. Mais il ne dit jamais le pourquoi l’architecture importe. Pourquoi certaines décisions te libèrent et d’autres te piègent.

Si tu rapproches les deux, voici ce que tu vois :

Étapes 1-3 (Mental Model) : Tu apprends ce qu’est un agentic AI engineer. Ce que c’est vraiment—pas juste « quelqu’un qui utilise Claude ». Mais pas encore de patterns reconnaissables. C’est la compréhension générale.

Étapes 4-8 (Building Blocks) : Tu apprends les outils. LangGraph. Les chaînes d’appels. Les workflows. C’est ici que Pattern 1 (Data-Driven Configuration) commence à avoir du sens. Tu réalises qu’une configuration d’agent ne devrait jamais être en dur. Que tu peux commencer à structurer tes agents comme des données.

Et c’est aussi où Pattern 2 (LIVE Orchestration) germe. Tu découvres que c’est le middleware qui décide quoi faire, pas le modèle. Tu commences à penser orchestration.

Étapes 9-13 (Build It Right) : Ici, les patterns explosent. C’est là où tu apprends à faire des systèmes qui tiennent vraiment.

• Pattern 5 vit dans les étapes 10 et 12, quand tu apprends à valider et évaluer. Graceful degradation c’est : « comment je suis sûr que ma configuration est valide avant de la déployer? Comment j’évalue si une nouvelle version est meilleure que l’ancienne? »

• Pattern 4 vit dans l’étape 11, le « maker-checker split ». Qui crée? Qui vérifie? Qui autorise? C’est l’injection de contexte. L’isolation par appel.

• Pattern 1 et 2 sont les colonnes vertébrales du système—tu reviens les affiner à travers toutes ces étapes, en réalisant que tu dois découpler la configuration de l’exécution, que tu dois orchestrer dynamiquement.

• Pattern 3 arrive quand tu demandes : « et si j’ajoute un nouvel agent ? Est-ce que je dois redéployer? » La réponse est non, si tu as bien compris les patterns.

Le vrai insight : le roadmap te dit quoi apprendre. Les 5 patterns, c’est le pourquoi de l’architecture. Le roadmap te donne les outils. Les patterns te donnent le jugement pour les utiliser correctement.

Tu peux maîtriser LangGraph (l’outil) sans comprendre Pattern 2 (le middleware orchestre, pas le modèle). Tu peux déployer en prod (l’étape finale) sans avoir compris Pattern 4 (l’injection de contexte par appel). Et ça se verra. Ton système sera fragile, rigide, ou non sûr.

Mais si tu intègres les 5 patterns pendant que tu apprends le roadmap, à chaque étape, tu vas construire un système qui est flexible, modulaire, sûr, et qui tient vraiment en production.

Conclusion : Ce qui distingue vraiment

Revenons au début. Un prompt engineer parle au modèle. Un agentic AI engineer construit un système que le modèle orchestre.

Mais c’est une simplifié. Ce qui nous distingue vraiment, ce ne sont pas juste les outils. Ce ne sont pas juste les frameworks. C’est le jugement architectural. C’est la capacité à reconnaître que les vraies décisions ne se font pas dans le prompt. Elles se font avant que le modèle ne pense.

Ces 5 patterns, c’est ce jugement codifié. C’est comment tu dis : « Je ne vais pas configurer un agent une fois et l’oublier (Pattern 1 te sauve). Je vais l’adapter en temps réel (Pattern 2). Je vais le composer avec d’autres agents sans risque (Pattern 3). Je vais m’assurer qu’il ne voit que ce qu’il doit voir (Pattern 4). Et je vais construire un système qui survit à ses propres erreurs (Pattern 5). »

Cette mentalité—ce changement de perspective—c’est ce qui sépare vraiment.

Tu ne demandes plus « comment je formule bien ma demande? » Tu demandes « comment je construis un système où les décisions sont bien distribuées? Où les données circulent au bon moment? Où la résilience est intégrée de facto? »

Accepter ces 5 patterns, c’est accepter que tu n’es plus un prompt engineer. Tu es un architecte de systèmes. Et ça change absolument comment tu vois chaque problème.

Si tu construis des systèmes agentic en ce moment—ou si tu veux commencer—et que tu sens qu’il y a des points de douleur (configurations rigides, orchestration floue, sécurité qui s’ajoute trop tard, résilience qui n’est pas assez bonne), ces patterns sont souvent la réponse. J’ai vu ça sur mon propre chemin, et je suis convaincu que ces 5 patterns sont les leviers que la majorité des gens ignore.

Si tu as des questions, si tu veux explorer comment appliquer ces patterns à ton propre système, ou si tu es en train de construire quelque chose d’agentic et que tu veux un regard extérieur pour te rassurer ou te challenger : je suis là pour ça. C’est littéralement ce pour quoi j’ai construit ma freelance.