L'ensemble des articles publiés, du plus récent au plus ancien.
Deux façons d'adapter un LLM à ton contexte : injecter du contexte au moment de la requête (RAG), ou modifier ses poids via des adapters LoRA. Le mécanisme diffère, et ça change tout sur quand utiliser lequel.
Un agent unique qui accumule outils et contexte finit par se noyer. Déléguer à des sous-agents spécialisés change la donne — au prix d'une coordination plus complexe.
Un seul appel LLM suffit pour beaucoup de tâches. La boucle agentique (penser, agir, observer, recommencer) n'est justifiée que dans des cas précis — lesquels, et à quel coût.
Un serveur MCP mal exposé donne à un LLM les mêmes accès qu'un utilisateur malveillant qui aurait trouvé la faille. Permissions, sandboxing, confused deputy : les contrôles concrets à mettre en place.
Rôle système, few-shot, décomposition, sortie structurée : les techniques de prompt engineering qui ont un effet mesurable, sans la mystique qui entoure souvent le sujet.
Comparaison honnête des trois familles de modèles propriétaires en 2026 : prix, contexte, latence, points forts. Aucun gagnant absolu, des choix selon le cas d'usage.
Un provider LLM tombe ou te 429 en plein pic. Sans plan de repli, ton produit tombe avec lui. Patterns de dégradation gracieuse entre modèles et providers.
Property hooks, visibilité asymétrique, nouvelles fonctions de tableau, chaînage sans parenthèses. Ce que PHP 8.4 change concrètement pour du code backend, sans le bruit.
Un agent qui boucle sur des tools est une boîte noire si tu ne traces rien. Ce qu'il faut logger pour pouvoir débugger, optimiser et facturer.