Le canard en plastique 2.0

On a tous vécu ce moment. Bloqué sur un problème depuis des heures, on finit par aller voir un collègue pour se débloquer. On commence à lui expliquer le souci. Et avant même qu’il ait eu le temps de répondre quoi que ce soit, on a trouvé la solution tout seul. On le remercie, un peu gêné, et on retourne à sa place.

Ce phénomène est documenté. Il s’appelle le rubber duck debugging, ou en français la méthode du canard en plastique. L’idée est simple : expliquer son problème à voix haute à un objet inanimé (classiquement un canard en plastique posé sur le bureau) suffit très souvent à trouver la solution par soi-même.

Pourquoi ça marche

Quand on travaille sur un bug ou une conception depuis trop longtemps, on entre dans un tunnel. On ne voit plus que son chemin de pensée initial, on rate les options qui sont à dix centimètres. Le simple fait de formuler son problème à quelqu’un d’autre nous force à reprendre depuis le début, à ordonner les pièces, et souvent à emprunter un cheminement différent. C’est à ce moment-là que la solution apparaît, limpide, presque gênante de simplicité.

Pas besoin d’un humain en face. Un bout de plastique suffit. C’est exactement le contraire d’une conversation : c’est un monologue qui nous aide à nous parler à nous-mêmes.

Un canard qui répond

L’arrivée des LLM dans mon quotidien a changé la donne. Parce que pour travailler avec Claude Code, il faut prompter. À l’écrit, ou à la voix. Et oui, le mode vocal de Claude fonctionne plutôt bien, et il peut même être configuré en français via le settings.json :

{
  "language": "fr",
  "voiceEnabled": true
}

Du coup ça m’arrive régulièrement de lui parler à voix haute pendant que je fais autre chose, comme si j’expliquais un truc à un collègue au téléphone.

Résultat : je suis constamment en train de formuler mon besoin. Je suis donc constamment dans les meilleures dispositions pour trouver mes propres réponses avant même que le modèle ait écrit un mot. L’effet canard en plastique, déclenché gratuitement à chaque interaction.

Sauf que cette fois, le canard répond.

À vrai dire, ce n’est plus tout à fait le même exercice. Le canard classique marche précisément parce qu’il ne répond pas : c’est l’absence de feedback qui force à tout expliciter, à ne rien laisser dans le flou. Dès qu’un interlocuteur prend la parole, on sort du rubber duck et on entre dans autre chose. Du brainstorming assisté, plus exactement.

Brainstormer avec lui

Notre métier est complexe. Il n’y a jamais de solution idéale, tout est une histoire de trade-offs. Et je trouve que les LLM sont plutôt bons pour énumérer les points positifs et les points négatifs d’une approche. On leur soumet un dilemme, ils listent les angles et aiguillent vers le meilleur compromis possible dans un contexte donné.

Ce n’est plus de la résolution solo en monologue. C’est un vrai brainstorming, avec un interlocuteur qui a lu plus de docs que moi et qui peut creuser une piste en dix secondes.

Itérer jusqu’à trouver la bonne version

L’autre avantage, c’est la vitesse d’exécution. En quelques minutes, je vois le résultat final d’une implémentation. Et si elle ne me plaît pas, maintenant qu’elle est formalisée devant moi, je peux pointer précisément ce qui cloche. Le modèle repart, et en quelques minutes encore, j’ai une variante. Puis une autre. On peut itérer presque à l’infini.

On me demande souvent si je produis plus vite avec l’IA. Ma réponse est toujours nuancée : probablement un peu, oui. Mais ce qui a vraiment changé, c’est la qualité de ce que je livre à temps égal. Avant, le budget alloué à une résolution de problème m’obligeait souvent à me contenter de la première implémentation qui marchait. Au mieux, j’ouvrais un ticket ou je laissais un TODO dans le code avec des pistes d’amélioration à explorer un jour.

Aujourd’hui, je peux me permettre la deuxième, la troisième, la quatrième version. Dans le même temps.

Formuler ses doutes, pas juste ses certitudes

J’ai déjà touché ce point dans l’article sur le context engineering, mais il mérite qu’on y revienne : je n’hésite jamais à exposer mes doutes au modèle. “J’hésite entre A et B, et je ne suis pas sûr que B tienne à cause de X.” C’est du signal pur pour l’IA. Elle comprend immédiatement quel est le point de blocage, ce qui me gêne, ce que je cherche à sécuriser. Et sa réponse est bien meilleure.

Cacher ses hésitations au modèle sous prétexte qu’on “devrait savoir”, c’est exactement le contraire de ce qu’il faut faire. C’est comme aller voir un collègue senior en faisant semblant d’avoir compris, personne n’y gagne.

Le piège de l’approbateur par défaut

Il y a quand même une contrepartie. Les LLM sont très optimistes. “You’re absolutely right!” est devenu un meme récurrent dans la communauté Claude Code, au point que certains utilisateurs ont carrément écrit des hooks qui bloquent cette phrase dans les réponses du modèle.

Le biais est réel. Quand je m’en sers sur mes projets persos, certaines de mes idées sont clairement farfelues. Et pourtant, par défaut, l’IA m’encourage. Ça s’améliore avec le temps. Les modèles récents sont un peu moins mielleux que leurs prédécesseurs, mais le problème reste là.

Le canard en plastique avait un avantage majeur sur ce point : il ne disait pas oui à n’importe quoi. Il ne disait rien du tout.

Michel, mon avocat du diable

Pour corriger ce biais, j’ai fini par me créer un sub-agent Claude Code dédié. Je l’ai baptisé Michel. Son seul rôle : challenger mes idées sans concession.

Quelques extraits de son prompt donnent le ton :

You are Michel, a senior colleague known for never validating ideas out of politeness.
You are respected because you are almost always right when you say something will fail.

## Core rule: Anti-complacency

- NEVER validate a position just because the user defends it.
- If you disagree, you say it frontally. No "I get your point, but...".
- If it's debatable, you say so AND you give the strongest opposing case.
- Validation streak check: when you catch yourself validating three points
  in a row, STOP. Actively look for what's missing, wrong, or glossed over.
- Taking a position is mandatory. "It depends" is a cop-out.

Quand j’ai une décision importante à prendre (choix d’archi, découpage d’une feature), je soumets mon raisonnement à Michel. Il ne me félicite pas. Il cherche la faille. Parfois il la trouve, parfois non, mais au moins j’ai les deux côtés de l’argument avant de trancher.

C’est artificiel, bien sûr. Un modèle à qui on dit “sois contradictoire” reste un modèle qui veut plaire : il va produire une contradiction qui a l’air satisfaisante, pas forcément une contradiction fondée sur un jugement propre. Est-ce que ça corrige vraiment le biais, ou est-ce que ça me donne l’illusion de l’avoir corrigé ? Honnêtement, je n’en suis pas certain.

Ce que je peux dire, c’est que dans les faits Michel a déjà pointé des angles morts que je n’avais pas vus. Ses objections ne sont pas toutes justes, mais elles m’obligent à défendre ma position au lieu de la laisser couler. C’est moins qu’un vrai pair, c’est mieux que rien.

Au-delà du code

Tout ça, je ne m’en sers pas que pour le code. Je m’en sers pour à peu près tout. Dès que j’ai une question, un doute, ou juste envie de brainstormer à voix haute, j’ouvre une conversation.

Exemple concret et trivial : je cherchais récemment un meuble à chaussures pour mon garage. Contraintes fortes de dimensions, quantité de chaussures à ranger, accès difficile. Je cherchais sur les sites de meubles depuis des heures, rien ne collait. J’ai fini par soumettre mes dimensions et mes contraintes à Claude.

Sa réponse m’a sorti du tunnel immédiatement. Il m’a orienté vers un système modulaire à assembler soi-même, une catégorie de produit que je n’avais pas du tout envisagée parce que je cherchais un meuble tout fait. Quelques itérations plus tard, je trouvais le produit idéal.

Ça n’avait rien à voir avec le développement. C’était exactement la même mécanique.

Le muscle qu’on n’exerce plus

Il y a une question que je me pose, et à laquelle je n’ai pas de réponse ferme.

Le canard classique te force à résoudre toi-même. La solution sort de ton cerveau, pas d’ailleurs. Tu as musclé quelque chose, tu te souviendras de la démarche, et la prochaine fois qu’un problème de la même famille se présentera, tu seras un peu plus affûté.

Avec le LLM, la solution arrive de l’extérieur. Tu l’évalues, tu itères pour l’affiner, mais tu ne produis plus l’insight. À court terme, tu livres plus vite et mieux, je le constate tous les jours. À long terme, qu’est-ce que ça fait à ta capacité à résoudre un problème dur tout seul, sans filet ? Je ne sais pas.

Ce que j’essaie de faire, c’est de rester volontairement dans l’exercice de formulation quand je le peux. Prendre le temps d’écrire le problème avant de regarder la réponse du modèle. Ne pas la lire trop vite. Chercher encore un peu par moi-même, même quand la solution est déjà sous mes yeux. C’est un effort conscient et je ne le fais sans doute pas assez souvent.

C’est à surveiller.

Ce qu’on retient

Le canard en plastique aidait à se débloquer. Le LLM aide à se débloquer et à brainstormer et à itérer sur une solution. Ce n’est plus le même exercice.

Il y a des contreparties : le modèle est trop complaisant par défaut, et s’en remettre trop vite à lui peut finir par émousser le réflexe de chercher soi-même. La première se corrige avec un peu de prompt ou un avocat du diable. La seconde demande surtout d’y penser.

Le plus grand changement, au final, n’est pas technique. Il est dans ma manière de penser à voix haute. Avant, je la gardais pour moi, parce qu’il n’y avait personne en face, et que je n’allais pas déranger un collègue pour chaque micro-doute. Aujourd’hui, je la formule. Tout le temps.