Assumer ce que vous construisez

Objectifs

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

• Expliquer ce que recouvre la Diligence quand vous livrez un produit construit avec l’IA
• Adopter trois habitudes qui vous gardent maître d’un code que vous n’avez pas écrit vous-même
• Décider, avant de livrer : livrer, corriger ou arrêter

Propriétaire d’un code que vous n’avez pas écrit

Au fil du cours, vous avez délégué, décrit et discerné. Votre outil fonctionne ; il est presque temps de le livrer.

Dans le framework 4D, la Diligence consiste à assumer la responsabilité de ce que vous construisez avec l’IA : un usage transparent, éthique et redevable. Concrètement, c’est déclarer votre usage de l’IA, assumer les résultats qu’elle produit, vérifier avant de livrer, mesurer l’impact de ce que vous construisez sur les autres, et respecter les politiques, les règles de confidentialité et les normes professionnelles qui encadrent l’IA dans votre organisation ou votre secteur.

Vous êtes responsable du résultat, pas seulement du livrable : « c’est l’IA qui l’a écrit » n’explique rien et n’excuse rien.

Avec l’IA, vous pouvez vous retrouver propriétaire d’un code que vous n’avez pas écrit. La Diligence, c’est la façon de rattraper votre propre code : le comprendre, le mettre à l’épreuve, le tester, et installer les dispositifs qui attrapent ce qui vous échappe. Dans la vidéo de la leçon officielle, Martina, de l’équipe d’ingénierie d’Anthropic, montre à quoi cela ressemble au quotidien. Trois habitudes en ressortent.

Habitude 1 : faire remonter les décisions cachées

Quand vous écrivez du code vous-même, vous découvrez en chemin des choses auxquelles vous n’aviez pas pensé : un cas limite, une décision dont vous ignoriez qu’elle devait être prise. Avec l’IA, ces décisions sont parfois prises sans jamais vous être soumises. Recréez cette étape volontairement, pour les remettre sur la table là où vous pouvez peser :

• quand un cas limite vous vient à l’esprit, demandez-le simplement : « Peux-tu vérifier qu’un utilisateur ne peut pas voir les fichiers d’un autre utilisateur ? » ;
• après une construction conséquente, demandez directement : « Quelles hypothèses et quels compromis as-tu faits ? Quels risques de sécurité devrais-je connaître ? »

Habitude 2 : dire ce que l’IA a écrit

Quand Claude a écrit l’essentiel d’une pull request, indiquez-le dans sa description, non comme une excuse mais comme une information. Car l’IA ne fait pas le même genre d’erreurs qu’un humain : des API dépréciées utilisées avec assurance, un code propre localement mais incohérent avec le reste de la base, un comportement inventé pour des cas que vous n’aviez pas spécifiés. Un relecteur qui le sait peut adapter sa revue.

Habitude 3 : prendre le temps de comprendre

On peut se sentir dépassé quand l’IA construit à votre place, et se retrouver avec un code qui marche sans le comprendre, ce qui n’était pas vraiment possible avant. Ce n’est pas que vous ne pouvez pas le comprendre : c’est devenu une étape à part, et l’IA peut aussi vous y aider. Claude prendra volontiers le temps de vous l’expliquer patiemment. Cela demande un peu de temps, mais c’est ce qui vous remet dans la boucle.

Les bonnes pratiques d’avant valent encore plus

Les bonnes pratiques d’ingénierie d’avant l’IA restent valables, peut-être plus encore : vous livrez plus vite et vous comprenez une part plus faible de ce que vous livrez.

• Les tests restent le moyen le plus simple de ne rien casser en allant vite. Une suite solide fige le comportement auquel vous tenez, pour itérer sans crainte : l’habitude d’écrire les tests d’abord est ce qui vous permet de continuer à changer les choses en confiance après le lancement.
• L’observabilité n’a pas disparu : certaines choses n’apparaissent qu’avec de vrais utilisateurs. Journaux, suivi des erreurs, tableaux de bord : vous devez l’apprendre par vos propres données, pas par l’e-mail d’un utilisateur.
• Les feature flags, ces interrupteurs qui activent ou coupent une fonctionnalité sans redéployer, restent utiles quand quelque chose passe entre les mailles.

Livrer a aussi son vocabulaire technique — migrations, gestion des versions, limitation du débit, feature flags — que l’IA ne vous signalera pas si vous ne le demandez pas.

Prototyper librement, livrer sélectivement

Un code bon marché ne crée de la valeur que s’il s’accompagne d’une évaluation honnête. Prototypez autant que vous voulez ; livrez seulement ce que vous pouvez défendre. Et sachez renoncer à ce que vous avez construit quand les faits montrent que ce n’est pas la bonne chose : l’effort déjà investi est l’une des choses les plus difficiles à abandonner, mais le travail du builder n’est pas de défendre le logiciel, c’est de servir l’utilisateur.

Enfin, l’accès est une décision de conception. Avant de déclarer un produit livré, vérifiez qui vos hypothèses excluent.

À vous de jouer

Livrer le projet « temps d’attente ». La livraison est le moment où la Diligence devient réelle. Avant de déployer, répondez honnêtement à chacune de ces questions :

• Compréhension — Pouvez-vous expliquer ce que fait votre code, et pas seulement ce qu’il devrait faire ?
• Tests — Vos tests d’acceptation passent-ils toujours ? Avez-vous testé les cas limites : centre fermé, données manquantes, temps d’attente nul ?
• Accès — Qui votre outil sert-il mal ?
• Responsabilité — Ce résultat pourrait-il être mal lu ou détourné ? Avez-vous été transparent sur le rôle de l’IA ?
• Boucle de retour — Comment saurez-vous si l’outil fonctionne une fois livré ?

Une fois ces questions traitées, déployez votre outil ou hébergez-le comme prototype, partagez-le avec trois vrais utilisateurs, et faites une itération à partir de ce que vous apprenez, avec des tests qui vérifient le changement.

Questions de réflexion

• Comment votre vision de l’intégration de l’IA a-t-elle évolué depuis le début du cours ?
• Quelle chose ferez-vous autrement dans votre travail avec l’IA, à partir de ce que vous avez appris ?

Sources officielles : Stand behind what you build (Claude Academy, vidéo et sa transcription)

Points clés à retenir

• Vous êtes responsable du résultat, pas seulement du livrable : « c’est l’IA qui l’a écrit » n’explique et n’excuse rien
• Faites remonter les hypothèses, dites ce que l’IA a écrit, prenez le temps de comprendre votre code
• Livrer a son vocabulaire technique (migrations, versions, limitation du débit, feature flags) que l’IA ne fera pas surgir sans qu’on le lui demande
• Les tests rendent l’itération sûre après le lancement ; l’observabilité vous prévient avant vos utilisateurs
• Prototypez librement, livrez sélectivement ; l’accès est une décision de conception

Crédits et licence — Adaptation française de la leçon « Stand behind what you build » 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.