Tu peux devenir fluide avec les systèmes agentiques sans les comprendre. La fluidité, c'est connaître les patterns — comment structurer un prompt, quels frameworks utiliser, à quoi ressemblent les modes d'échec courants et comment les corriger. La compréhension, c'est savoir pourquoi les patterns fonctionnent, ce qu'ils font réellement, et quoi faire quand le pattern s'effondre. L'écart entre les deux reste invisible jusqu'à ce que tu tombes sur un problème qui sort des patterns que tu connais.

Le piège de la fluidité est particulièrement facile à éviter dans un domaine qui bouge vite et récompense ceux qui livrent rapidement. Tu apprends les pratiques qui marchent, tu les appliques de façon fiable, tu bâtis une réputation de quelqu'un qui sait ce qu'il fait. Et tu sais ce que tu fais — dans l'espace des problèmes qui ressemblent à ceux que tu as déjà résolus. Le problème inédit révèle l'écart.

Comprendre dans ce domaine, c'est avoir un modèle mental de ce qui se passe réellement quand un agent traite un prompt. Pas les détails mathématiques de l'attention des transformers, mais la compréhension fonctionnelle : ce que le modèle fait quand il génère du texte, pourquoi l'emplacement du contexte importe, pourquoi les exemples surpassent les instructions, pourquoi le même prompt se comporte différemment selon les modèles. C'est cette compréhension qui te permet de raisonner sur de nouveaux problèmes plutôt que de faire du pattern-matching sur d'anciennes solutions.

Le test, c'est de savoir si tu peux expliquer pourquoi quelque chose fonctionne. Pas juste que ça fonctionne — pourquoi. Si tu ne peux pas expliquer pourquoi la structure de ton prompt produit de meilleurs résultats que l'alternative, tu opères sur de la superstition. C'est peut-être une superstition fiable — le pattern marche assez constamment pour que ton manque de compréhension ne te nuise pas aujourd'hui. Mais la superstition ne se généralise pas. La compréhension, oui.

Le chemin de la fluidité vers la compréhension passe par l'examen délibéré des choses que tu fais automatiquement. Pourquoi cette section du system prompt vient-elle en premier ? Que se passerait-il si elle venait en dernier ? Pourquoi utilises-tu trois exemples plutôt qu'un ? Qu'apporte chaque exemple supplémentaire ? Ces questions semblent pédantes quand le système fonctionne. Elles deviennent essentielles quand il ne fonctionne plus.

Sache que ça marche. Sache pourquoi ça marche. Le second est plus difficile et vaut davantage.