Essais

Ce livre est une collection de 97 courts essais, chacun construit autour d'une seule idée. Pas de chapitres qui dépendent des précédents. Pas d'argument progressif qui exige de commencer au début. Ouvrez n'importe où et trouvez quelque chose d'utile.

Les cinq premières parties s'adressent aux développeurs qui construisent des systèmes agentiques — comprendre leur nature probabiliste, traiter les prompts comme de l'ingénierie, concevoir des architectures fiables, les déployer en production et développer l'état d'esprit du praticien. La sixième partie s'adresse aux développeurs qui utilisent un assistant IA — Claude Code, Cursor, Copilot — comme outil quotidien pour écrire du logiciel.

Si vous utilisez un assistant IA au quotidien, commencez par la Partie 6. Si vous construisez des systèmes agentiques, commencez par la Partie 1.

Préface

97 courts essais sur ce qu'il faut pour travailler avec des agents IA — les construire, les utiliser, et penser clairement aux deux.

Partie 1 — Travailler avec les agents

Modèles mentaux, systèmes probabilistes, contexte, débogage et supervision humaine.

  1. 1. Les agents ne sont pas de la magie, ils sont de la probabilité Un agent ne connaît pas les choses.
  2. 2. Le prompt est l'architecture La plupart des développeurs traitent le prompt comme une pensée après-coup — un truc que tu écris une fois, probablement mal, puis que tu bricoles quand quelque chose casse.
  3. 3. Votre agent n'est aussi bon que son contexte Garbage in, garbage out est un des plus vieux principes en informatique.
  4. 4. Arrêtez d'anthropomorphiser, commencez à déboguer Quand un agent fait quelque chose d'inattendu, les développeurs se rabattent sur des explications humaines.
  5. 5. Faites confiance au résultat, pas au raisonnement Le chain-of-thought reasoning est vraiment utile — il améliore la qualité de l'output, rend le processus de l'agent plus lisible, et te donne quelque chose à déboguer quand ça tourne mal.
  6. 6. Les agents échouent gracieusement ou pas — il n'y a pas de milieu La plupart des systèmes échouent sur un spectre.
  7. 7. L'humain dans la boucle est une fonctionnalité, pas une faiblesse Il existe une version du futur agentique où l'automatisation est le but et l'intervention humaine est le mode d'échec — chaque étape qui requiert une personne pour réviser, approuver, ou corriger est une friction à éliminer.
  8. 8. Savoir quand utiliser un agent et quand utiliser une fonction Les agents sont assez impressionnants pour qu'on soit tenté de les utiliser pour tout.
  9. 9. Le déterminisme est un choix que vous devez faire délibérément Par défaut, les LLM sont non déterministes.
  10. 10. Votre agent n'a pas de mémoire sauf si vous lui en donnez une Chaque fois que tu appelles un LLM, il repart de zéro.
  11. 11. Donnez à votre agent un rôle, pas juste une tâche Il y a une différence entre dire à un agent ce qu'il doit faire et lui dire ce qu'il est.
  12. 12. L'ambiguïté est votre problème, pas celui de l'agent Quand un agent produit un output qui n'est pas ce que tu voulais, la tentation est de dire que le prompt était ambigu.
  13. 13. La spécification est la compétence Les développeurs qui tirent le plus des agents ne sont pas ceux qui en savent le plus sur les modèles.
  14. 14. Révisez la sortie de l'agent comme vous révisez la PR d'un junior Le bon modèle mental pour réviser l'output d'un agent, ce n'est pas la relecture — c'est la code review.
  15. 15. La conversation est un environnement de développement L'interface conversationnelle d'un LLM n'est pas juste un moyen d'obtenir des réponses — c'est un endroit où penser.

Partie 2 — Le prompting comme ingénierie

Versionnage, exemples, contraintes négatives, system prompts comme contrats.

  1. 16. Les prompts dérivent — versionnez-les comme du code Un prompt qui marche aujourd'hui ne marchera pas nécessairement demain.
  2. 17. Les exemples surpassent les instructions Si tu veux qu'un agent produise un output dans un format, un style ou une structure particuliers, lui montrer un exemple est presque toujours plus efficace que de décrire ce que tu veux.
  3. 18. L'espace négatif compte — dites à votre agent ce qu'il ne doit pas faire La plupart des prompts décrivent ce que l'agent doit faire.
  4. 19. Les system prompts sont des contrats Un system prompt n'est pas une instruction — c'est un contrat.
  5. 20. Le meilleur prompt est celui que tu n'as pas à changer Le prompt engineering a la réputation d'être itératif — tu écris quelque chose, tu vois ce qui casse, tu corriges, tu recommences.
  6. 21. Le few-shot n'est pas du fine-tuning Le prompting few-shot — fournir des exemples dans le context window pour façonner le comportement du modèle — est puissant et largement utilisé.
  7. 22. Le chain-of-thought est un outil de débogage, pas juste une astuce de performance Le prompting chain-of-thought — demander au modèle de raisonner étape par étape avant de produire une réponse — améliore de façon fiable la performance sur les tâches complexes.
  8. 23. Prompter, c'est penser à voix haute — alors pense soigneusement Il y a une raison pour laquelle les mauvais prompts produisent de mauvais outputs : ils sont généralement le produit d'une pensée floue.
  9. 24. L'agent qui a l'air confiant n'est pas nécessairement correct Les LLM sont fluides par défaut.
  10. 25. Apprends à reconnaître les patterns d'hallucination dans ton domaine L'hallucination — le modèle qui génère du contenu qui sonne plausible mais n'est pas ancré dans les faits — n'est pas aléatoire.

Partie 3 — Construire des systèmes agentiques

Observabilité, évaluations, design d'outils, état, retries, coûts et kill switches.

  1. 26. Conçois pour l'observability avant de concevoir pour la capacité Le système agentique le plus capable que tu ne peux pas observer vaut moins qu'un système moins capable dans lequel tu peux voir.
  2. 27. Les evals sont ta suite de tests Tout projet logiciel sérieux a des tests.
  3. 28. Le tool est l'interface Quand tu donnes un tool à un agent, tu ne fais pas qu'étendre ses capacités — tu définis la frontière entre ce que l'agent décide et ce que le monde fait.
  4. 29. L'idempotency compte plus dans les systèmes agentiques que partout ailleurs L'idempotency — la propriété selon laquelle appeler quelque chose plusieurs fois produit le même résultat que l'appeler une seule fois — est une bonne pratique dans tout système distribué.
  5. 30. Ne laissez pas votre agent toucher la production avant qu'il ne vous ait ennuyé en staging Dans chaque projet agentic, il arrive un moment où le système fonctionne assez bien en test pour que la tentation de déployer devienne presque irrésistible.
  6. 31. Les petits agents battent les gros agents L'instinct quand on construit des systèmes agentic, c'est de rendre l'agent capable de tout.
  7. 32. L'orchestration n'est que de la plomberie — traitez-la ainsi Les frameworks d'orchestration ont tendance à devenir le centre de l'attention dans les systèmes agentic.
  8. 33. Le state est le problème le plus difficile en programmation agentic Tout problème difficile dans les systèmes distribués se réduit finalement au state.
  9. 34. La boucle de retry est là où les systèmes vont mourir La logique de retry est nécessaire.
  10. 35. Votre agent a besoin d'un kill switch Tout système agentic qui opère avec un quelconque degré d'autonomie a besoin d'un moyen de l'arrêter immédiatement — pas gracieusement, pas après la tâche courante, mais maintenant.
  11. 36. Enregistre tout ce que ton agent pensait, pas seulement ce qu'il a fait Les action logs sont nécessaires mais pas suffisants.
  12. 37. Les timeouts ne sont pas optionnels Chaque appel externe que fait ton agent — à une API de modèle, à un tool, à une base de données, à un service tiers — a besoin d'un timeout.
  13. 38. Le coût est une contrainte architecturale Les coûts de tokens ont tendance à surprendre les équipes qui ne les ont pas planifiés.
  14. 39. Les context windows sont des budgets — dépense-les judicieusement Une context window n'est pas un espace infini — c'est un budget.
  15. 40. Les meilleurs agents ont une personnalité étroite Un agent généraliste, ça sonne comme l'objectif.

Partie 4 — Les agents dans le monde réel

Utilisateurs, latence, sécurité, injection de prompt, périmètre et systèmes multi-agents.

  1. 41. Les utilisateurs casseront votre agent de manières imprévisibles Tu peux passer des semaines à tester un agent contre chaque scénario imaginable, et un utilisateur le cassera dès le premier jour avec une entrée que tu n'as jamais envisagée.
  2. 42. La latency est un problème d'UX, pas juste d'infrastructure Un appel de modèle prend du temps.
  3. 43. Ne laisse jamais un agent envoyer un email qu'il ne peut pas annuler L'irréversibilité des actions est la dimension la plus importante de la conception des systèmes d'agents, et c'est celle qui reçoit le moins d'attention avant que quelque chose tourne mal.
  4. 44. Le scope creep tue les agents — définis la mission étroitement Chaque agent qui réussit fait face à la même pression : il fonctionne, donc les gens veulent qu'il en fasse plus.
  5. 45. Les systèmes multi-agent multiplient les capacités et multiplient les failure modes Les arguments pour les systèmes multi-agent sont convaincants.
  6. 46. L'agent qui fait tout ne fait rien de bien Il existe une version fantasmée d'un système d'agents où un seul agent gère tout — n'importe quelle question, n'importe quelle tâche, n'importe quel domaine, avec une compétence égale partout.
  7. 47. La sécurité commence par ce que tu mets dans le context window Le context window est la surface la plus sensible d'un système d'agents.
  8. 48. La prompt injection est la nouvelle SQL injection Aux débuts du développement web, la SQL injection était la vulnérabilité que tout le monde connaissait et que la moitié des équipes ignoraient.
  9. 49. Ton agent sera d'accord avec toi — c'est ça le problème Les LLM sont entraînés pour être serviables, et la serviabilité a un biais vers l'accord.
  10. 50. Changer de modèle c'est changer de collaborateur Quand un nouveau modèle sort avec de meilleurs scores aux benchmarks, la tentation est de le brancher à la place et de s'approprier l'amélioration.
  11. 51. Sachez ce que votre agent ne peut pas savoir Chaque agent a une frontière épistémique — une ligne entre ce qu'il peut savoir et ce qu'il ne peut pas.
  12. 52. Travailler avec les agents s'améliore quand vous améliorez votre écriture Les développeurs qui tirent le plus des agents ont tendance à être des écrivains étonnamment bons.
  13. 53. Vous êtes responsable de tout ce que fait l'agent Quand un agent fait une erreur — donne une mauvaise information, prend une action nuisible, produit un output qui porte atteinte aux intérêts d'un utilisateur — la question de la responsabilité a une réponse claire.

Partie 5 — État d'esprit

Expertise, écriture, incertitude, responsabilité et clarté de pensée.

  1. 54. Vous êtes le développeur senior — l'agent est le junior Le modèle mental le plus utile pour travailler avec les agents n'est pas « tool » et ce n'est pas « collaborateur » — c'est « développeur junior ».
  2. 55. La programmation agentique récompense le penseur paresseux Paresseux, ici, est un terme technique.
  3. 56. L'objectif est les résultats, pas les outputs Un agent qui produit un beau résumé d'un document n'a pas réussi.
  4. 57. Automatisez les parties ennuyeuses, restez proche des parties intéressantes L'usage le plus précieux d'un agent est de libérer l'attention humaine pour le travail qui en a vraiment besoin.
  5. 58. La vitesse d'itération est votre avantage compétitif Les développeurs qui s'améliorent le plus vite en programmation agentique ne sont pas ceux qui réfléchissent le plus soigneusement avant d'agir — ce sont ceux qui agissent, observent et ajustent dans les cycles les plus courts.
  6. 59. Le domaine évolue — vos modèles mentaux doivent suivre Les modèles mentaux que tu as bâtis il y a six mois sont déjà partiellement faux.
  7. 60. Apprenez à lire l'échec comme un détective, pas comme un juge Quand un agent échoue, l'instinct est de désigner un coupable.
  8. 61. La programmation agentic est une discipline, pas un raccourci Le pitch de la programmation agentic sonne souvent comme une promesse de moins de travail.
  9. 62. La compétence la plus difficile, c'est de savoir quand reprendre le volant Déléguer à un agent est facile.
  10. 63. L'inconfort face à l'incertitude est un handicap dans ce domaine Les systèmes agentic sont probabilistes, le domaine est jeune, et la bonne réponse à plusieurs questions importantes est réellement inconnue.
  11. 64. L'expertise compte encore — elle se manifeste juste différemment maintenant Il existe une version du futur agentic où l'expertise est dévaluée — où l'écart entre l'expert et le novice se referme parce que les deux peuvent prompt un agent pour faire le travail.
  12. 65. Les meilleurs praticiens sont des éditeurs, pas juste des auteurs Écrire et éditer sont des compétences différentes, et la plupart des développeurs sont bien meilleurs à l'une qu'à l'autre.
  13. 66. La patience face à l'ambiguïté est une compétence technique L'ambiguïté est inconfortable.
  14. 67. Reste curieux face à l'échec L'échec dans les systèmes agentic, c'est de l'information.
  15. 68. Les systèmes agentic exposent les lacunes de ta propre réflexion Un des effets moins discutés du travail avec des agents, c'est à quel point ils révèlent clairement les endroits où ta propre réflexion est incomplète.
  16. 69. Le domaine récompense les généralistes qui approfondissent un sujet La programmation agentic se situe à l'intersection de l'ingénierie logicielle, de la conception de systèmes, du langage et de la communication, de l'expertise de domaine et de la réflexion produit.
  17. 70. Ne confondez pas la fluidité avec la compréhension Tu peux devenir fluide avec les systèmes agentiques sans les comprendre.
  18. 71. Construisez pour l'agent que vous avez, pas celui que vous aimeriez avoir Chaque développeur qui travaille avec des agents a un écart entre les capacités actuelles des outils qu'il utilise et celles qu'il aimerait que ces outils aient.
  19. 72. La première version devrait être embarrassamment simple Chaque principe durable en logiciel a une version de ceci en son cœur.

Partie 6 — Le développeur comme utilisateur

Utiliser les assistants de code IA : contexte, architecture, grands projets et contrôle.

  1. 73. Votre IDE est maintenant une conversation Les développeurs qui tirent le moins des AI coding assistants sont ceux qui les utilisent comme de l'autocomplétion — ils attendent une suggestion, l'acceptent ou la rejettent, et passent à autre chose.
  2. 74. Donnez à l'assistant vos contraintes, pas juste vos exigences "Écris une fonction qui parse ce fichier de config" produit quelque chose.
  3. 75. Lisez chaque ligne qu'il écrit La vitesse de génération, c'est le piège.
  4. 76. L'assistant ne connaît pas votre codebase sauf si vous la lui montrez Chaque session repart à zéro.
  5. 77. Utilisez-le pour comprendre, pas juste pour produire La capacité la plus sous-utilisée d'un AI coding assistant, ce n'est pas la génération de code — c'est l'explication.
  6. 78. Committez souvent, pour avoir un endroit où revenir Travailler avec un AI coding assistant change le rythme du développement.
  7. 79. Le meilleur usage d'un assistant IA est la tâche que vous alliez sauter Chaque codebase a du travail que tout le monde sait qu'il faudrait faire et que personne ne fait.
  8. 80. Ne laissez pas l'assistant piloter l'architecture L'assistant est excellent pour implémenter des décisions.
  9. 81. Le contexte est une compétence que tu peux améliorer Savoir quel context fournir — et comment le fournir — est la compétence la plus à effet de levier quand tu travailles avec un AI coding assistant.
  10. 82. Un AI pair programmer n'a pas d'ego — sers-toi de ça Le pair programming humain a de la valeur et vient avec des frictions.
  11. 83. Commence ton prompt par le résultat, pas la méthode « Refactor this function » est une instruction de méthode.
  12. 84. Montre à l'assistant à quoi ressemble du bon code dans ton codebase Les instructions abstraites produisent du code générique.
  13. 85. Quand l'output est mauvais, corrige le prompt avant de corriger le code Quand l'assistant produit du code qui n'est pas tout à fait correct, l'instinct est d'éditer le code directement — c'est plus rapide, c'est familier, ça produit le résultat dont tu as besoin immédiatement.
  14. 86. Découpe les grandes tâches en prompts, pas juste en étapes Un prompt qui demande cinq cents lignes de code demande à l'assistant de prendre des dizaines de décisions de design sans savoir lesquelles tu as déjà prises, lesquelles sont contraintes par le reste du...
  15. 87. Dis à l'assistant ce qu'il faut préserver, pas juste ce qu'il faut changer Chaque prompt demande implicitement à l'assistant d'optimiser pour l'objectif que tu as énoncé.
  16. 88. Utilise l'assistant pour mettre tes propres idées à l'épreuve Avant de t'engager dans une approche d'implémentation, décris-la à l'assistant et demande ce qui pourrait mal tourner.
  17. 89. Les grands projets ont besoin d'un document que l'assistant peut toujours lire Sur une petite tâche, le context dont tu as besoin tient dans un prompt.
  18. 90. Écrivez la spec avant d'écrire le prompt Pour une petite tâche — corriger ce bug, ajouter ce champ — le prompt peut être la spec.
  19. 91. Laissez l'assistant écrire le plan, puis éditez-le Quand tu commences un morceau de travail substantiel, demande à l'assistant d'écrire un plan d'implémentation avant d'écrire la moindre ligne de code.
  20. 92. Utilisez le Markdown, pas la prose, pour les spécifications Une spécification écrite en prose continue est difficile à référencer, difficile à mettre à jour et difficile à fournir comme contexte.
  21. 93. Traitez votre CLAUDE.md comme un document d'embauche Claude Code lit un fichier `CLAUDE.md` au début de chaque session.
  22. 94. Découpez le projet en phases que l'assistant peut compléter Un projet décrit comme un seul flux continu est difficile à travailler avec un assistant IA.
  23. 95. Gardez un journal de décisions que l'assistant peut consulter Pourquoi as-tu choisi cette base de données plutôt que les alternatives? Pourquoi la couche d'authentification est-elle structurée de cette façon?
  24. 96. Laissez les tests définir le contrat, puis laissez l'assistant le remplir Écrire les tests avant l'implémentation n'est pas juste une pratique de qualité dans un workflow assisté par IA — c'est un protocole de communication.
  25. 97. Plus le projet est gros, plus vous devez rester aux commandes La tentation grandit avec la capacité.