I. Le jouet à 80 milliards
Il existe un document que vous devriez lire. Pas long, pas caché, ne demande pas de compétences juridiques particulières. À l’adresse microsoft.com/en-us/microsoft-copilot/for-individuals/termsofuse, mis à jour le 24 octobre 2025, il contient une phrase qui mérite d’être prise au sérieux. Dans la section, en majuscules et gras, « IMPORTANT DISCLOSURES & WARNINGS », elle dit : Copilot est à considérer comme étant à des fins de divertissement uniquement. Il peut faire des erreurs et ne pas fonctionner comme prévu. Ne vous appuyez pas sur Copilot pour des conseils importants. Utilisez Copilot à vos propres risques.
Si ça vous semble la clause d’une appli à mèmes, je vous comprends. Mais nous parlons du produit que Microsoft a intégré à Windows 11, Excel, PowerPoint, Teams, Outlook — au cœur d’une suite que plus de 430 millions de personnes utilisent chaque jour. Le produit pour lequel Microsoft a engagé environ 80 milliards de dollars de capex IA pour le seul exercice 2025 — datacenters, infrastructure, capacité de calcul — auxquels s’ajoutent les quelque 13 milliards investis cumulativement dans OpenAI, dont la techno alimente les modèles sous-jacents. Le produit vendu aux grandes entreprises 30 $ par utilisateur et par mois, et 21 (réduits à 18 avec les promos du premier semestre 2026) aux PME. Les ToU de ce produit disent que c’est un jouet.
La réaction de Microsoft, quand la clause a circulé sur les réseaux début avril 2026, a été prévisible. Un porte-parole a déclaré à PCMag qu’il s’agissait d’« un langage legacy » qui « ne reflète plus l’usage actuel du produit » et qui serait « modifié à la prochaine mise à jour ». Pas de date. Aucun engagement contraignant. Aucune explication sur le maintien d’un langage qui ne reflète pas la réalité dans des documents légaux après tant de mois, sous les yeux du même service juridique qui les rédige. Le porte-parole en a parlé comme on parle d’un panneau oublié sur un chantier fermé. Mais les chantiers fermés ne facturent pas 30 $ par siège.
Tentation de classer ça comme bourde du juridique. Faux. Les ToU ne s’écrivent pas par distraction. Ils sont pesés mot à mot par des avocats sachant qu’ils serviront en audience. « Entertainment » n’est pas un synonyme paresseux d’« expérimental » ou « beta ». Entertainment a un sens juridique précis dans le droit anglo-saxon : c’est la catégorie qui protège qui produit du contenu déclarativement non factuel — jeux, fiction, simulations. Dire qu’un produit est « for entertainment purposes only », c’est dire qu’aucun utilisateur raisonnable ne devrait attendre que les réponses soient exactes, fiables ou adaptées à un usage pratique.
On objectera que les chiffres racontent une autre histoire. Que l’adoption de Copilot est plus lente que prévu. Que Microsoft sait que le produit a des problèmes. Vrai. Au T2 FY2026, seuls 15 millions de sièges sur 450 millions de sièges commerciaux payants étaient abonnés à M365 Copilot : 3,3 %. La part des abonnés payants aux US a chuté de 39 % en six mois (de 18,8 % en juillet 2025 à 11,5 % en janvier 2026). Le NPS sur l’exactitude des réponses est passé de –3,5 à –24,1 entre juillet et septembre 2025, selon Recon Analytics. 44,2 % de ceux qui abandonnent Copilot citent la défiance dans les réponses comme motif principal. Quand les salariés peuvent choisir librement entre Copilot, ChatGPT et Gemini, seuls 8 % choisissent Microsoft.
Ces chiffres n’atténuent pas le problème. Ils l’aggravent. Ils montrent que Microsoft sait parfaitement que le produit n’est pas fiable, le déclare dans les documents juridiques, et continue de le vendre comme outil de productivité enterprise. Satya Nadella a appelé Copilot « a true daily habit » devant les investisseurs. Le marketing le présente comme l’assistant qui transforme votre façon de travailler. Les ToU disent que c’est un jouet. Pas une contradiction. Une stratégie.
II. Le chœur des disclaimers
Il serait malhonnête de présenter la clause Microsoft comme une anomalie. Elle ne l’est pas. C’est le cas le plus spectaculaire d’un pattern qui traverse toute l’industrie IA, qu’il vaut la peine de cartographier.
OpenAI, dans ses ToU, prévient les utilisateurs de ne pas s’appuyer sur les outputs comme unique source de vérité ou d’information factuelle, et limite sa responsabilité agrégée à 100 $ ou au montant payé pendant les douze mois précédents. Google, dans les ToU de Gemini, écrit de ne pas s’appuyer sur les services pour des conseils médicaux, mentaux, juridiques, financiers ou autres conseils professionnels. xAI, l’entreprise d’Elon Musk, prévient que son IA est « probabiliste par nature » et peut produire des outputs erronés. Aucune de ces entreprises, pour être juste, n’est allée jusqu’au « for entertainment purposes only ». Cela reste une exclusivité Microsoft.
La différence entre Microsoft et les autres n’est pas de fond. Elle est de nuance. Tous les grands fournisseurs d’IA construisent un mur juridique entre le produit qu’ils vendent et les conséquences de son usage. Ils le font en sachant que leurs modèles peuvent produire — et produisent — des outputs faux, trompeurs, potentiellement nuisibles. En août 2024, Copilot a faussement identifié le journaliste allemand Martin Bernklau comme un pédophile condamné et un escroc, en fournissant aussi son adresse personnelle. Microsoft n’a bloqué les requêtes sur Bernklau qu’après une plainte pour protection des données. Ce ne sont pas des cas-limites. C’est le fonctionnement ordinaire d’un système probabiliste vendu commercialement comme s’il était déterministe.
Et les disclaimers, en justice, fonctionnent. Le 19 mai 2025, la Superior Court du comté de Gwinnett, Géorgie, a prononcé un summary judgment en faveur d’OpenAI dans Walters v. OpenAI (23-A-04860-2). L’animateur radio Mark Walters avait poursuivi OpenAI après que ChatGPT, à la demande d’un journaliste, avait généré un faux résumé d’un procès où Walters figurait accusé de détournement de fonds aux dépens de la Second Amendment Foundation. Le tribunal a rejeté l’action sur trois motifs indépendants : les déclarations ne pouvaient être raisonnablement comprises comme des faits réels (notamment parce que ChatGPT avait averti le journaliste de ses limites et que les ToU contenaient des disclaimers explicites sur la possibilité d’erreurs) ; Walters n’avait démontré ni négligence ni malice d’OpenAI ; et Walters avait admis n’avoir subi aucun dommage. Une issue qui tient sur plusieurs jambes, pas seulement sur les disclaimers. Mais les disclaimers ont pesé, et pèsent. Le tribunal a explicitement reconnu que les avertissements répétés sur la possibilité d’« hallucination » contribuaient à rendre déraisonnable toute attente d’exactitude factuelle de la part de l’utilisateur.
C’est ici que beaucoup s’arrêtent, indignés. Mais c’est ici que le propos doit devenir plus précis, parce que tous les disclaimers ne sont pas équivalents, ne servent pas le même but, et ne sont pas tous, en soi, négatifs.
L’AI Act européen, le Règlement 2024/1689, exige explicitement que les fournisseurs de systèmes IA communiquent les limites de leurs produits. L’article 13 impose que les systèmes à haut risque soient suffisamment transparents pour permettre aux deployers d’interpréter les outputs et de les utiliser correctement, et qu’ils soient accompagnés d’instructions concises, complètes, exactes et claires sur caractéristiques, capacités et limites. L’article 14 impose une supervision humaine effective et prescrit que les superviseurs soient mis en mesure de rester conscients de la possible tendance à se reposer automatiquement ou excessivement sur les outputs — l’« automation bias ». L’article 50 exige que l’utilisateur soit informé qu’il interagit avec un système IA et que les contenus générés soient marqués comme tels.
Dire « ce système IA peut se tromper, vérifie toujours, ne lui fais pas une confiance aveugle » n’est donc pas seulement légitime. C’est une obligation. L’Europe a posé que la transparence sur les limites des systèmes IA est un pilier de la sécurité et de la confiance. L’utilisateur doit savoir avec quoi il interagit, quels sont les risques, et il doit pouvoir ignorer ou outrepasser tout output. C’est le cadre que toute entreprise sérieuse devrait suivre.
Mais une chose est de dire « ce système a ces limites, voici comment le superviser pour l’utiliser sûrement ». Une autre est de dire « c’est un jouet de divertissement, utilise-le à tes risques, on ne garantit rien ». La première formule, c’est de la transparence. C’est de la conformité avec l’AI Act. Un acte de responsabilité qui met le deployer en mesure de faire son travail. La seconde est un transfert de responsabilité déguisé en transparence. Elle ne met pas l’utilisateur en mesure d’utiliser le système correctement : elle le met en incapacité de se retourner quand ça tourne mal.
L’AI Act demande au fournisseur de déclarer les limites pour permettre un usage sûr. Les ToU de Microsoft déclarent les limites pour empêcher tout recours. L’un sert l’utilisateur. L’autre sert le service juridique. Et quand un tribunal américain valorise les disclaimers d’un fournisseur en rejetant une action en diffamation, il ne récompense pas nécessairement la transparence. Il prend acte du legalese.
III. La directive qui change tout (et l’angle mort)
D’ici au 9 décembre 2026, les États membres de l’UE doivent transposer en droit national la Directive 2024/2853, la nouvelle Product Liability Directive. Premier remaniement en quarante ans du régime européen de responsabilité du fait des produits défectueux. Pour les entreprises qui produisent, intègrent ou distribuent du logiciel et des systèmes IA, les conséquences sont profondes.
La directive redéfinit d’abord ce qu’est un « produit ». La directive de 1985 était conçue pour un monde d’objets physiques : voitures, électroménager, jouets. La nouvelle inclut explicitement le logiciel, indépendamment du mode de fourniture ou d’utilisation — qu’il soit embedded, standalone, cloud ou SaaS. Elle inclut firmware, OS, applications. Les Considérants précisent que les systèmes d’intelligence artificielle relèvent aussi de la définition. Le logiciel n’est plus un service qui échappe à la responsabilité produit. C’est un produit. À ce titre soumis à responsabilité objective : pas besoin de prouver la faute du producteur. Il suffit de prouver que le produit était défectueux et que le défaut a causé un dommage.
Reste la question des clauses d’exonération. L’article 10 dispose que les États membres garantissent que la responsabilité d’un opérateur économique au titre de la directive ne peut être limitée ou exclue, vis-à-vis de la personne lésée, par une disposition contractuelle ou par le droit national. Formulation sans ambiguïté. Disclaimers dans les ToU, clauses limitatives, formules « as is » et « for entertainment purposes only » : dès lors qu’un consommateur européen subit un dommage du fait d’un produit défectueux, elles ne valent rien.
Comprenez la portée transatlantique. La clause « Copilot is for entertainment purposes only » continuera à fonctionner aux États-Unis, où Walters v. OpenAI a confirmé que les tribunaux prennent les disclaimers au sérieux. En Europe, après transposition de la directive, cette même clause devient inapplicable. Si Copilot génère un output défectueux causant un dommage à une personne physique (mort, blessures, dommages psychologiques médicalement reconnus, destruction ou corruption de données non professionnelles, dégâts à des biens privés), le fournisseur répond. Indépendamment de ce qui est écrit dans les ToU.
La directive réécrit aussi les règles de la charge de la preuve, et là ça se complique. Elle introduit des présomptions en faveur de la victime. Si le défendeur ne divulgue pas les informations pertinentes, le défaut est présumé. Si le produit n’est pas conforme à des exigences obligatoires de droit national ou européen, le défaut est présumé. S’il y a un dysfonctionnement manifeste lors d’un usage raisonnablement prévisible, idem. Si la victime rencontre « des difficultés excessives » à prouver le défaut en raison de la complexité technique ou scientifique du produit, les tribunaux peuvent présumer à la fois le défaut et le lien de causalité. Pour les systèmes IA, où l’opacité interne est structurelle et non accidentelle, cette présomption sera la norme. La victime n’aura pas à expliquer le fonctionnement du modèle qui a généré l’output faux. Elle devra démontrer que l’output était défectueux et que le dommage en a découlé.
La PLD s’imbrique avec tout le cadre normatif européen. La non-conformité aux exigences du Cyber Resilience Act (security-by-design, gestion des vulnérabilités, mises à jour de sécurité) peut constituer une présomption de défectuosité. Idem pour le non-respect des obligations NIS2. Et idem, implicitement, pour les exigences de l’AI Act : un système IA qui ne respecte pas les obligations de transparence, supervision humaine, exactitude et robustesse est un système qui ne respecte pas des exigences obligatoires de droit européen, et donc un système pour lequel la PLD peut présumer la défectuosité.
Le court-circuit saute aux yeux. L’AI Act demande aux fournisseurs de déclarer les limites pour permettre un usage sûr. La PLD dit que si le produit cause un dommage, le fournisseur répond indépendamment des disclaimers. Le fournisseur est obligé d’informer que son système peut se tromper, et en même temps il ne peut pas utiliser cette information comme bouclier quand le système se trompe effectivement. Régime cohérent, conçu pour protéger le consommateur. Mais qui crée une tension forte entre devoir de transparence et impossibilité d’utiliser cette transparence comme bouclier.
Pour Microsoft, la tension est gérable. Pour qui se trouve au milieu de la chaîne, elle peut être létale.
IV. Qui modifie, paie : l’intégrateur comme bouc émissaire structurel
La PLD ne se contente pas de dire que le producteur du logiciel répond. Elle élargit la chaîne des opérateurs économiques potentiellement responsables, selon une logique en cascade pensée pour qu’un consommateur européen ait toujours un interlocuteur joignable dans l’UE. Si le manufacturer est hors UE, c’est l’importateur. Sinon le représentant autorisé. Puis le fulfilment service provider. Puis le distributeur, s’il n’identifie pas l’opérateur pertinent dans le mois de la demande de la victime. La responsabilité est solidaire : plusieurs opérateurs répondant du même dommage répondent ensemble, chacun pour le tout.
Jusqu’ici, le système paraît raisonnable. Mais il y a une figure que la PLD traite avec une dureté particulière, cruciale pour comprendre les implications pratiques de la clause « entertainment only » : quiconque modifie substantiellement un produit après sa mise sur le marché est considéré comme un manufacturer du produit modifié et est responsable dans la mesure où le défaut résulte de la modification. Les Considérants précisent qu’une modification substantielle peut découler aussi d’une mise à jour logicielle, d’un upgrade, ou de l’apprentissage continu d’un système IA. Le produit ainsi modifié est considéré comme mis sur le marché au moment où la modification est effectivement opérée.
Pensez à ce qui se passe dans le réel. Un system integrator, une software house, un consultant IT prend Copilot et l’intègre dans un workflow d’entreprise. Il configure les prompts, branche les sources de données du client, personnalise les réponses, automatise les flux. Modifie-t-il substantiellement le produit ? Selon la PLD, très probablement oui. Le moment où vous prenez un modèle généraliste pour le spécialiser sur un contexte précis, vous créez un produit différent. Si ce produit modifié génère un output défectueux causant un dommage, l’intégrateur répond comme manufacturer.
L’article 12 prévoit une protection spécifique pour les micro et petites entreprises produisant un logiciel défectueux intégré au produit d’autrui. Elles peuvent, par accord contractuel avec le manufacturer du produit final, se protéger des actions récursoires. Mais cette protection a deux limites qui en réduisent fortement l’utilité. Première : elle ne protège en aucun cas la micro/petite entreprise d’une action directe du consommateur. Le consommateur peut toujours agir directement contre l’intégrateur, et l’intégrateur répond. Seconde : la protection contre les actions récursoires exige un accord contractuel avec le manufacturer du produit. Microsoft n’a aucune obligation et aucun incitatif à concéder ces accords aux SI qui utilisent Copilot. Ses ToU disent déjà que le produit est « for entertainment purposes only » et que l’utilisateur est « solely responsible » de toute action prise sur la base des outputs. Dans une éventuelle action récursoire, Microsoft pourra dire : on vous avait prévenus. Vous avez choisi vous-mêmes de l’intégrer dans un produit professionnel. Ce n’est pas notre faute si vous l’avez vendu à un client comme outil fiable alors que nous-mêmes vous avions dit que c’était un jouet.
La PLD empêche de déverser la responsabilité vers le bas — c’est-à-dire vers le consommateur — par des clauses contractuelles. Mais elle n’empêche pas les grands de refuser des protections contractuelles vers le haut, dans la relation entre intégrateur et manufacturer. Résultat : l’intégrateur est exposé au consommateur sans pouvoir se protéger contractuellement, et n’a aucune garantie de pouvoir efficacement se retourner contre Microsoft. Microsoft a les avocats, les représentants autorisés dans chaque État membre, la masse financière pour absorber le contentieux. L’intégrateur de dix personnes à Pescara, à Brno, à Lisbonne, non.
L’objection évidente : l’intégrateur peut et doit implémenter la supervision humaine prévue par l’AI Act. Mettre en place processus de vérification, formation, supervision des outputs. C’est vrai. L’intégrateur responsable le fera, et devra le faire aussi pour ses propres obligations de deployer sous AI Act. Mais la PLD ne demande pas si vous avez fait de votre mieux. La PLD demande si le produit était défectueux et si le défaut a causé un dommage. Un output faux d’un système IA intégré dans un workflow professionnel qui cause un dommage à une personne physique est un produit défectueux, indépendamment du nombre de couches de supervision humaine implémentées. Vous pouvez avoir tout bien fait et répondre quand même.
Pensez à ce qui arrive quand un système IA intégré dans un ERP génère un rapport financier erroné menant à une mauvaise décision d’investissement. Ou quand un assistant IA intégré à un CRM produit une communication diffamatoire sur un client. Ou quand un système d’analyse intégré à une plateforme de santé fournit une indication erronée influençant un parcours diagnostique. Dans tous ces cas, sous la PLD, la victime peut agir contre l’intégrateur. L’intégrateur est là, dans l’UE, joignable, avec un code SIRET et un compte en banque. Microsoft est à Redmond. Et dans ses ToU, c’est écrit que Copilot est pour le divertissement.
V. La facture et qui la paie
Il y a un moment, dans l’histoire de la régulation technologique, où l’on voit clairement que les règles ont été écrites pour un monde qui n’existe plus. La PLD de 1985 était pensée pour un monde d’objets physiques fabriqués par des entreprises identifiables, vendus par des chaînes linéaires, utilisés par des consommateurs qui pouvaient raisonnablement en juger la sécurité. La nouvelle PLD est une mise à jour nécessaire et à bien des égards admirable : elle étend la protection au logiciel, abaisse les barrières pour les consommateurs, introduit des présomptions qui rééquilibrent l’asymétrie informationnelle. Mais le monde qu’elle régule n’est pas fait de chaînes linéaires. Il est fait de couches superposées, d’API qui appellent des API, de modèles probabilistes dont le fonctionnement interne n’est compréhensible même pas par leurs constructeurs.
L’architecture logique du cadre européen est la plus avancée au monde. L’AI Act fixe les obligations de transparence, supervision humaine, gestion du risque. Le Cyber Resilience Act impose security-by-design et mises à jour continues. NIS2 étend la cybersécurité à des secteurs critiques. La PLD ferme la boucle en disant que celui qui viole ces obligations et cause un dommage paie. L’objection ne porte pas sur la logique du cadre. Elle porte sur la distribution pratique des conséquences.
Les conséquences, dans la réalité, suivent une loi de gravitation économique qu’aucune directive ne peut inverser : elles tombent vers le bas. Vers qui a moins de ressources juridiques, moins de masse financière, moins de capacité d’absorption du contentieux. Microsoft, Google, OpenAI ont chacune des centaines d’avocats, des représentants autorisés dans chaque juridiction, des budgets juridiques qui dépassent le CA de filières entières de PME. Elles ont écrit des ToU qui, même inopposables au consommateur sous la PLD, restent pleinement opérationnels comme arguments dans les actions récursoires entre opérateurs économiques. Elles ont classifié leurs produits comme « entertainment », « probabilistic », « not a source of truth » avec une précision chirurgicale, sachant quel rôle chaque mot jouerait dans une procédure future.
La PLD présente la facture, mais qui la paie ? Le system integrator de dix personnes qui a pris Copilot, l’a intégré dans le gestionnaire du client, a fait de la formation, mis en place la supervision humaine, et qui découvre que quand l’output défectueux génère un dommage, c’est lui qui est joignable, identifiable, attaquable. Le fournisseur est de l’autre côté de l’océan, ou protégé par des clauses contractuelles B2B, des arbitrages à Dublin, et des limitations de responsabilité entre opérateurs économiques que la PLD ne touche pas, parce qu’elles concernent des rapports entre professionnels et non la protection directe du consommateur.
Il serait faux de dire que la PLD est une erreur. La PLD est incomplète. Son incomplétude produit un effet régressif qui récompense ceux qui ont les ressources pour naviguer le système et pénalise ceux qui ne les ont pas. L’article 12 reconnaît le problème pour les micro/petites entreprises, mais le résout circulairement : on te protège contre le récursoire si tu as un accord contractuel avec le manufacturer. Mais le manufacturer n’a aucune obligation de te le concéder. Et si dans ses ToU c’est écrit « entertainment only », son incitatif à te le concéder est même négatif : signer cet accord reviendrait à admettre implicitement que le produit a un usage professionnel, contredisant son propre bouclier.
Paradoxe supplémentaire. Les entreprises qui prennent le plus au sérieux la conformité, qui mettent en place la supervision humaine, qui informent les clients, qui documentent les processus, sont aussi celles qui laissent la trace documentaire la plus riche pour une action en responsabilité. Qui intègre Copilot à la va-vite, sans processus, sans doc, sans supervision, est paradoxalement plus difficile à attaquer faute de preuves d’un rapport structuré avec le produit. La PLD, en cherchant à protéger le consommateur, risque d’inciter à la superficialité : qui fait bien est plus exposé que qui fait mal.
Considérons la dimension temporelle. La PLD s’applique aux produits mis sur le marché ou en service après la transposition. Mais les systèmes IA ne sont pas des produits statiques. Ils sont mis à jour en continu. Les modèles changent. Les outputs changent. Un système IA qui marche aujourd’hui d’une manière pourrait, dans six mois, après un update du modèle sous-jacent, marcher tout autrement. Chaque mise à jour substantielle, selon les Considérants, remet le produit sur le marché. L’intégrateur qui a construit un workflow sur Copilot en 2025 pourrait se retrouver, après un update du modèle en 2027, avec un produit substantiellement différent générant des outputs différents, sans contrôle sur la modification et avec pleine responsabilité de ses effets.
Je n’ai pas de solution clef en main. Mais qui travaille dans ce secteur devrait commencer à lire les ToU de ses fournisseurs IA non pour s’indigner, mais pour saisir exactement ce que le fournisseur refuse de garantir, parce que cette liste est la carte du risque résiduel qui reste sur les épaules de l’intégrateur. Il devrait négocier des accords contractuels spécifiques sur la responsabilité produit avant la transposition de la PLD, parce qu’après le pouvoir de négociation sera encore moindre. Il devrait documenter chaque processus de supervision humaine, chaque évaluation de risque, chaque information au client — non parce que cela élimine la responsabilité PLD, mais parce que dans une action récursoire la documentation est la seule arme. Et il devrait poser sérieusement la question de la soutenabilité assurantielle de l’intégration de systèmes IA tiers dans des produits professionnels — car aujourd’hui la plupart des polices RC pro ne couvrent pas les dommages de sortie d’IA, et demain cette couverture sera nécessaire.
Quand Microsoft écrit « for entertainment purposes only », elle ne bafouille pas. Elle parle clair, et délibérément. Elle dit que la responsabilité de tout usage professionnel du produit n’est pas la sienne. Elle dit que celui qui prend ce produit et le vend comme outil fiable le fait entièrement à ses risques. L’Europe a bâti un cadre normatif qui en théorie tient tout le monde responsable. En pratique, il tient pour responsables ceux qui peuvent le moins se le permettre. Le fournisseur qui a écrit « for entertainment purposes only » sachant pertinemment que personne ne le lirait, qui a empoché 30 $ par siège et par mois sachant pertinemment que son produit n’était pas fiable, celui-là a encore ses avocats, ses clauses, ses arbitrages internationaux. La prochaine fois qu’on lui demandera des comptes, il ressortira les Terms of Use. Tout y est écrit. Il suffit de lire.
Ce qu'il faut retenir
« For entertainment purposes only » est un terme juridique chirurgical, pas un slogan : il signale qu’aucun utilisateur raisonnable ne devrait attendre de l’exactitude, et il est écrit pour un tribunal américain où les disclaimers fonctionnent (cf. Walters v. OpenAI).
La PLD entrant en vigueur en décembre 2026 fait du logiciel un produit à responsabilité objective et rend les clauses d’exonération inapplicables vis-à-vis du consommateur — un « usage à vos risques » n’efface pas une responsabilité imposée ex lege.
La modification substantielle active la responsabilité du manufacturer : l’intégrateur qui configure des prompts, branche des données et spécialise Copilot pour un client est un producteur au sens de la PLD, directement attaquable par le consommateur lésé.
La protection de l’article 12 pour micro et petites entreprises est circulaire — elle exige un accord contractuel avec le manufacturer, et Microsoft a un incitatif négatif à le concéder, parce que le signer contredirait son bouclier « entertainment ».
La PLD punit ceux qui font les choses bien : les intégrateurs qui documentent supervision et compliance laissent la trace documentaire la plus riche pour une action en responsabilité, alors que ceux qui bossent à la va-vite sont paradoxalement plus difficiles à attaquer.
Questions & réponses
Que disent vraiment les Terms of Use de Microsoft Copilot ?
Mot pour mot, dans la section « IMPORTANT DISCLOSURES & WARNINGS » à jour au 24 octobre 2025 : Copilot est « à des fins de divertissement uniquement », peut commettre des erreurs, ne doit pas servir de base à des conseils importants, doit être utilisé à vos risques. Ce sont les conditions du produit pour lequel Microsoft a engagé environ 80 milliards de dollars de capex IA en FY2025 et qu’elle vend en entreprise pour 30 $/utilisateur/mois.
Clause legacy oubliée ou choix délibéré ?
Délibéré. Les Terms of Use ne s’écrivent pas par distraction — chaque mot est pensé pour une salle d’audience. Cette formule construit une position défensive pré-contentieux : si un client enterprise utilise Copilot pour une décision pro et qu’il y a dommage, Microsoft a déjà écrit noir sur blanc qu’on ne devait pas s’y fier. La responsabilité du défaut bascule sur l’utilisateur.
Comment cette clause se concilie-t-elle avec la PLD européenne ?
Mal. La nouvelle PLD entrant en vigueur en décembre 2026 traite le logiciel comme un produit industriel à responsabilité objective : le producteur répond des défauts indépendamment de la négligence. Une clause « usage à vos risques » n’efface pas la responsabilité imposée ex lege. La contradiction entre les ToU et la PLD deviendra matière à contentieux avant de devenir matière à amendements volontaires.
Que devrait faire une entreprise qui utilise Copilot aujourd'hui ?
Documenter explicitement où Copilot touche des décisions à impact (financier, RH, compliance, juridique). Ne pas accepter la clause d’irresponsabilité comme défaut contractuel. Traiter Copilot comme un sous-traitant avec SLA, pas comme un outil neutre de productivité. Et conserver les versions signées des ToU : elles deviendront des preuves quand arriveront les premiers cas.
L'auteur
