La Délégation et la boîte à outils du builder

Objectifs

À l’issue de cette leçon, vous serez capable de :

• Présenter la boîte à outils du builder et ce que l’IA apporte à chaque étape
• Expliquer pourquoi déléguer l’implémentation est sans danger, et pourquoi déléguer le jugement ne l’est pas
• Écrire des tests d’acceptation qui définissent « terminé » avant la première ligne de code

Le plus dur n’est pas d’écrire le code

Si vous avez déjà construit avec l’IA, vous l’avez sans doute remarqué : le plus difficile n’est pas de lui faire écrire du code, c’est de savoir quel code vous voulez qu’elle écrive. On pense souvent la délégation à l’IA comme une question fermée : oui ou non ? Pour un builder, c’est beaucoup plus riche. Un client vous apporte un problème. Comment le décomposer en quelque chose que vous pouvez réellement construire ? Et quel rôle l’IA joue-t-elle à chaque étape ?

Une image aide : imaginez-vous chef de projet, avec l’IA pour équipe. Un bon responsable ne se contente pas de distribuer des tâches. Il cadre le problème pour que chacun comprenne ce qu’il résout, fixe des objectifs pour que l’équipe sache à quoi ressemble un bon résultat, décide par quoi commencer et, surtout, sait quelles décisions prendre lui-même et lesquelles confier. C’est cela, la Délégation au sens du builder. Et elle commence bien avant la première ligne de code.

Les six capacités de la boîte à outils

Tout builder dispose d’une boîte à outils, souvent sans le savoir. Le cours la résume en six capacités, que vous mobilisez à différents moments d’un projet. L’IA peut aider sur les six, mais elle est bien plus forte sur certaines que sur d’autres :

Quelques exemples tirés du projet fil rouge :

• Empathie. Ce n’est pas ce que l’utilisateur dit vouloir, mais ce qui l’aidera vraiment. C’est le moment où vous parlez aux gens et observez ce qui les agace. L’IA peut organiser ce que vous apprenez, mais elle ne peut pas passer une matinée à l’accueil du centre de santé et remarquer que la secrétaire décroche quarante fois par jour parce que des patients appellent pour connaître le temps d’attente. Cette observation-là, c’est vous.
• Design. Un SMS ou une page web ? Des temps exacts ou des fourchettes ? Ce sont des arbitrages. L’IA peut générer des options ; le choix de celle qui convient vous revient.
• Architecture. L’IA a vu mille systèmes semblables à celui que vous esquissez, mais elle ignore vos contraintes, les compétences de votre équipe et ce que vous devrez changer dans six mois. Le binôme humain plus IA fonctionne très bien ici.
• Implémentation. Une fois que vous savez ce que vous construisez et comment c’est structuré, l’IA écrit du code qui fonctionne. C’est la capacité à déléguer le plus franchement. Si vous arrivez à cette étape sans tests ni critères de réussite clairement définis, vous avez probablement sauté une étape.
• Jugement. Est-ce que ça marche vraiment ? Est-ce que c’est bon ? Y mettriez-vous votre nom ? L’IA vous dira que le code tourne, pas si l’expérience sonne juste, si les cas limites comptent ou si vous avez résolu le vrai problème.
• Livraison. Communication, mesure, itération. L’IA peut rédiger les notes de version, mais elle ne voit pas l’utilisateur hésiter avant de cliquer.

L’IA est forte au milieu, faible aux bords

Regardez la forme de cette liste : l’implémentation est au milieu, et c’est là que l’IA est la plus forte. L’empathie, le jugement et la livraison sont vers les extrémités : l’IA y est faible, ou n’y fait qu’automatiser des étapes dont vous gardez la responsabilité. C’est l’idée clé du cours : les bords sont le travail humain, et c’est là qu’est la valeur.

Bien déléguer, en pratique, c’est passer du vrai temps au début d’un projet à comprendre pour qui vous construisez et à définir ce que réussir veut dire, puis inspecter les résultats avec scepticisme et garder les décisions de jugement entre vos mains. Avec un outil qui écrit du code instantanément, la tentation est de passer directement à la construction et de traiter l’empathie et le design comme du temps perdu. Résistez-y : plus l’IA accélère l’implémentation, plus votre valeur se déplace vers tout ce qui l’entoure.

Les builders qui réussiront ne seront pas ceux qui promptent le plus vite, mais ceux qui cadrent clairement les problèmes, savent à quoi ressemble un bon résultat avant de commencer, et font la différence entre du code qui tourne et du code qui compte.

Trois modes de collaboration

Pour chaque capacité, choisissez le mode de collaboration qui convient. Le framework AI Fluency en distingue trois :

• Automatisation : l’IA exécute, vous vérifiez ;
• Augmentation : vous travaillez la tâche ensemble, en allers-retours ;
• Agence : l’IA agit avec une marge de manœuvre, à l’intérieur de limites que vous avez fixées.

Des tests d’acceptation avant le code

Écrire les tests d’acceptation avant le code donne à vous et à l’IA une définition partagée de « terminé ». Un bon test est assez concret pour qu’un inconnu puisse dire si le produit le réussit ou non :

• Bon : « Un patient équipé d’un smartphone d’entrée de gamme trouve le temps d’attente actuel en moins de 30 secondes, sans créer de compte. »
• Mauvais : « Le système est facile à utiliser. »

À vous de jouer

Le projet « temps d’attente », partie 1. Ce projet traverse tout le cours : vous y reviendrez à chaque leçon et, à la fin, vous aurez construit quelque chose de réel. Mais dans cette leçon, vous n’écrivez aucune ligne de code. C’est voulu.

Le scénario. Un centre de santé de quartier veut permettre aux patients de consulter le temps d’attente avant de venir. C’est tout ce qu’on vous a dit. Votre travail consiste à faire ce qui précède la construction, en trois livrables.

Livrable 1 — Un brief du problème (une page maximum). Répondez simplement :

• Qui sont les utilisateurs ? Soyez précis : des patients, oui, mais lesquels ? Et le personnel ? Qui d’autre est concerné ?
• De quoi ont-ils réellement besoin ? Pas « d’un afficheur de temps d’attente » : quel résultat espèrent-ils ?
• Qu’est-ce qu’une excellente solution à l’usage ? Décrivez l’expérience, pas les fonctionnalités.
• Quelles sont les vraies contraintes ? Budget, compétences techniques du centre, accès des patients aux appareils, exigences de confidentialité.

Livrable 2 — Un plan de délégation. Faites un tableau de six lignes, une par capacité de la boîte à outils, et choisissez pour chacune le mode de collaboration qui convient : automatisation, augmentation ou agence.

Livrable 3 — Des tests d’acceptation. Écrivez cinq à sept énoncés qui définissent « terminé », chacun assez concret pour qu’un inconnu puisse dire si le produit le réussit ou l’échoue.

Sources officielles : Delegation & the builder’s toolkit (Claude Academy, vidéo, schéma interactif des six capacités et transcription)

Points clés à retenir

• Déléguer, c’est d’abord décomposer le problème, puis décider de ce que l’IA prend en charge à chaque étape
• L’IA est forte au milieu de la boîte à outils (l’implémentation) et faible aux bords (empathie, jugement, livraison)
• Écrivez les tests d’acceptation avant le code : ils donnent à vous et à l’IA une définition partagée de « terminé »
• Plus l’IA accélère l’implémentation, plus votre valeur se déplace vers le cadrage des problèmes et l’exigence de qualité

Crédits et licence — Adaptation française de la leçon « Delegation & the builder’s toolkit » du cours « AI Fluency for Builders » de Claude Academy, l’académie d’Anthropic, créé par Anthropic en partenariat avec CodePath. Les supports d’origine sont © 2026 Anthropic, publiés sous licence CC BY-NC-SA 4.0 ; cette adaptation, qui les traduit et les remanie, est diffusée sous la même licence.