À qui appartient le bug en prod : toi ou Claude ?

Début 2026. Je mergе une PR que Claude m'avait écrite pour le module slot-hold de crmcoaching. Je l'ai parcourue vite, la logique semblait cohérente, les types passaient. Deux jours plus tard, un bug de concurrence sur la réservation de créneaux : des doublons pouvaient se créer silencieusement sous charge. En cherchant la cause racine, je me suis posé une question que je n'avais pas vraiment formulée jusque-là : est-ce que la responsabilité appartient à Claude, ou à moi qui ai mergé sans vraiment lire ?

La réponse, je la connaissais au fond. Mais la formuler clairement a changé quelque chose dans ma façon de travailler. Voici ma position, ce que dit le droit en 2024-2025, et le contrat moral que j'ai formalisé en ADR dans crmcoaching.

"C'est Claude qui l'a écrit" : pourquoi cette excuse ne tient pas

D'abord, une observation issue de mes accompagnements de développeurs solos et d'équipes en 2025 : à la question "Quand un bug en prod vient de code que tu as généré avec Claude, à qui en revient la responsabilité ?", une part significative attribue au moins une partie de la responsabilité à l'outil lui-même.

Cette répartition révèle un glissement éthique réel. Le code généré par Claude ressemble à du code humain, donc on le traite comme s'il avait une intention, une responsabilité, un statut. Mais ce n'est pas du tout ce que dit le droit, ni ce qu'exige le craft, ni ce que documentent les principes Clean Code et software craftsmanship sur la responsabilité du développeur vis-à-vis de son code.

Ce que j'ai vécu : au moment où j'ai mergé la PR du module slot-hold, je n'avais pas pris le temps de dérouler mentalement les scénarios de concurrence. Claude avait produit du code structurellement correct pour le cas nominal. Mais je n'avais pas posé les bonnes questions, et je ne m'étais pas approprié le code au moment du merge. C'est ce passage manquant que j'identifie comme le vrai problème de fond.

Robert C. Martin avait proposé en 2015 un "Programmer's Oath" qui inclut cette phrase : "I will produce, with every release, a quick, sure, and repeatable proof that every element of the code works as it should." Le serment n'a pas de clause "sauf si l'IA l'a écrit". Le craft n'a pas d'exception sur l'origine du code. Si tu merges, tu attestes. Si tu attestes, tu portes.

Le droit 2023-2024 : l'IA n'a pas la personnalité juridique

Le cas le plus structurant est l'affaire Thaler v. Perlmutter, jugée par la D.D.C. en août 2023, confirmée en appel en mars 2025. Stephen Thaler avait tenté d'enregistrer un droit d'auteur sur une œuvre générée par son IA "Creativity Machine". L'US Copyright Office a refusé. Thaler a porté l'affaire en justice. La décision est claire : "Human authorship is a bedrock requirement of copyright. An AI cannot be the author."

Cette décision a deux conséquences directes pour tes PR Claude :

Conséquence 1 : le code généré par Claude n'a pas d'auteur autonome. Il a un prompter (la personne qui a écrit l'instruction), un éditeur (la personne qui a accepté ou modifié la suggestion), et un intégrateur (la personne qui a mergé). L'auteur juridique du code dans ton repo, c'est celui qui l'a fait entrer. Pas l'outil qui l'a suggéré.

Conséquence 2 : la responsabilité civile suit la même logique. Le US Copyright Office, dans son guidance "Copyright and Artificial Intelligence" publié en deux parties (2024 et début 2025), précise que la contribution humaine doit être "significative et identifiable" pour qu'il y ait propriété intellectuelle. Symétriquement, c'est cette même contribution humaine qui porte la responsabilité civile en cas de dommage causé par le code. Pas le fournisseur de l'IA, sauf cas extrême de défaut produit.

Le droit français suit une logique convergente. Le Conseil d'État, dans son étude de 2024 sur l'IA générative, rappelle que la responsabilité incombe à l'opérateur qui met le code en production, pas à l'éditeur de l'IA. Anthropic ne sera pas appelé à l'audience quand ta fonction transferFunds aura double-débité des clients (le scénario exact décrit dans le bug Claude du vendredi). Toi, oui.

La position craft : si tu merges, tu deviens l'auteur

Voici la position que j'affiche dans le premier ADR de gouvernance IA que j'ai écrit pour crmcoaching : "Tout code mergé dans le repo principal est considéré comme rédigé par le développeur qui a mergé la PR. Aucune décharge d'origine IA n'est recevable en post-mortem."

Cette phrase, à elle seule, change l'éthique de travail. Voici pourquoi.

Sans cette règle, l'incitation est de cliquer "Accept" sur la suggestion Claude, de regarder vite fait, de merger. Si ça plante, ce n'est "pas vraiment toi". Le travail mental d'appropriation est court-circuité par l'origine IA.

Avec cette règle, l'incitation se renverse. Si je merge, je suis l'auteur. Donc je lis. Donc je comprends. Donc je teste. Si je n'ai pas le temps de comprendre, je ne merge pas, ou je demande à Claude de simplifier jusqu'à ce que je comprenne. Cette discipline est exactement ce que la peur de l'automatisation pour les devs doit transformer en réflexe sain, pas en panique. C'est aussi ce qui se joue dans une revue de code structurée et appliquée : on n'approve pas ce qu'on n'a pas compris.

C'est aussi ce que Bruce Schneier appelait "taking ownership" dans son ouvrage Beyond Fear (2003). La sécurité, la fiabilité, la qualité ne sont pas des propriétés du code. Ce sont des engagements de personnes. Le code lui-même est neutre. Sa qualité dépend du dispositif humain qui l'entoure.

Le contrat moral du dev 2026 : 4 engagements

Voici les 4 engagements que j'ai formalisés dans l'ADR de gouvernance IA de crmcoaching.

Engagement 1 : je lis avant de merger. Aucune PR n'est mergée sans que j'aie lu chaque ligne et puisse en expliquer le fonctionnement. Si je ne peux pas expliquer une partie du code à voix haute en 60 secondes, c'est que je ne l'ai pas vraiment lue. Je retourne en draft.

Engagement 2 : je teste avant de croire. Tests verts sur le happy path ne valent pas attestation. Je vérifie les modes d'échec critiques (concurrence, timeout, partial failure) comme détaillé dans cet article sur les tests Claude. Si je n'ai pas testé, je n'ai pas validé. La Definition of Done sur la qualité doit explicitement intégrer cet engagement.

Engagement 3 : je trace les décisions architecturales. Si une PR introduit un nouveau pattern, une nouvelle dépendance, un trade-off, j'ouvre un ADR. Le code peut venir de Claude. La décision d'intégrer le code, et le trade-off associé, viennent de moi et restent tracés. Dans crmcoaching, plus de 50 ADRs documentent ces décisions.

Engagement 4 : j'assume en post-mortem. Si une PR que j'ai mergée cause un incident, je dis "j'ai mergé ce code" et pas "Claude l'a écrit". Cette discipline du langage n'est pas une simple posture, c'est le fondement d'un travail rigoureux.

Ces 4 engagements tiennent en une page. Ils transforment l'éthique de travail en quelques semaines. Et ils protègent juridiquement et professionnellement, parce qu'ils décrivent un dispositif de diligence raisonnable qu'un tribunal et un comité d'éthique peuvent reconnaître.

Comment écrire cet engagement en ADR de gouvernance

Voici le squelette de l'ADR que j'ai formalisé dans crmcoaching. Format Michael Nygard simplifié, en suivant le formalisme détaillé dans la pratique des ADR pour les décisions structurantes.

# ADR-001 : Gouvernance des contributions Claude dans le repo

## Statut
Acté - 2026-XX-XX

## Contexte
J'utilise Claude pour générer du code dans crmcoaching. La question
de la responsabilité du code IA-généré n'avait pas été tranchée
formellement. Elle apparaissait en post-mortem et créait une ambiguïté
sur la chaîne de responsabilité.

## Décision
1. Tout code mergé est attribué à l'auteur de la PR. Pas de mention "généré par Claude".
2. Chaque PR assistée par Claude doit s'accompagner d'une auto-déclaration :
   "j'ai lu, testé et compris ce code, je l'assume comme si je l'avais écrit."
3. Les 4 engagements du contrat moral (lecture, test, ADR, post-mortem)
   sont rappelés dans le PR template GitHub.
4. En post-mortem, l'origine Claude d'un bout de code n'est pas une circonstance
   atténuante. Elle peut être mentionnée pour information process, mais ne
   modifie pas l'attribution de responsabilité.

## Conséquences
+ Renforcement de la discipline de review et d'appropriation
+ Clarté juridique en cas d'incident
+ Alignement avec la jurisprudence (Thaler v. Perlmutter, 2023)
- Légère charge cognitive supplémentaire à chaque PR
- Tentation initiale de se défausser sur Claude en cas d'incident

Cet ADR fait 30 lignes. Il prend 1 heure à drafter. Il se révise tous les 12 mois. Il est la pierre angulaire d'une gouvernance IA mature, et il ouvre la voie à des discussions plus fines sur d'autres sujets comme les vulnérabilités de sécurité dans le code LLM-généré ou la data privacy avec les prompts envoyés à Claude.

La post-mortem où j'apprends à dire "je", pas "Claude"

Voici un exercice concret que j'ai traversé personnellement avec le bug du module slot-hold, et que je documente pour tout dev solo ou tech lead qui se retrouve dans la même situation.

Étape 1, à chaud. Quand le bug est apparu, mon premier réflexe a été de penser "Claude m'a donné du code incorrect". J'ai reformulé mentalement : "j'ai mergé du code qui ne gérait pas la concurrence". Le changement de sujet dans la phrase a tout modifié. La question devenait : pourquoi je n'ai pas vu ça au moment de la review ?

Étape 2, à froid. Deux jours plus tard, j'ai repris la PR. Le pattern de concurrence était effectivement absent. Claude n'avait pas été prompté pour les cas de charge simultanée. C'est une lacune dans mon instruction, pas un défaut mystérieux de l'outil. Le vrai sujet : comment structurer mes reviews pour que les scénarios critiques soient couverts avant le merge ?

Sur chaque post-mortem où j'applique cette discipline depuis, je sors avec "j'ai appris" plutôt que "c'est la faute de Claude". Le passage est mesurable : le bug suivant du même type n'arrive plus, parce que la cause racine est identifiée dans ma pratique, pas externalisée dans l'outil. C'est exactement ce que Sidney Dekker recommande dans The Field Guide to Understanding Human Error (2014) : la responsabilité humaine n'est pas une assignation morale, c'est un levier pour améliorer le système.

Ce que ça change concrètement

Depuis que j'ai installé l'ADR de gouvernance Claude dans crmcoaching, voici les changements observés en quelques mois de pratique.

Le gain le plus profond n'est pas dans les chiffres. Il est dans l'identité professionnelle. Un dev qui assume son code reste fier de ce qu'il livre. Un dev qui se défausse sur l'IA perd lentement le sens de son métier.

Conclusion

Ce que je veux que tu retiennes de cet article, c'est que la question "à qui appartient le bug" n'est pas un débat philosophique. C'est une décision opérationnelle qui structure ta façon de travailler. Si tu laisses l'ambiguïté s'installer, tu perds l'appropriation, tu perds la diligence, et au bout de quelques mois tu produis du code dont tu ne te sens plus vraiment l'auteur.

Le droit est clair : l'IA n'a pas la personnalité juridique. Le craft est clair : celui qui merge atteste. Traduire cette double clarté en un ADR explicite, un PR template, un langage de post-mortem : c'est un travail d'une heure qui change une pratique durable. Sans ce cadrage, l'éthique dérive lentement vers la déresponsabilisation. Avec ce cadrage, tu transformes Claude en outil au service d'un développeur responsable, plutôt qu'en alibi.

Si en lisant ces lignes tu reconnais ta situation, tu as deux choix. Tu peux laisser le prochain post-mortem se conclure par "C'est Claude qui l'a écrit". Ou tu peux commencer lundi matin, par un ADR d'une page et 4 engagements écrits noir sur blanc, et reprendre la souveraineté éthique de ton travail.

Pour la suite des patterns de gouvernance Claude que je documente chaque semaine, retrouve-moi sur mon profil Instagram kamangacode.

FAQ sur la responsabilité du code Claude-généré