Claude en entreprise : cas d'usage concrets par métier

Claude en entreprise sert surtout aux tâches où le texte est la matière première : comprendre un document long, produire un premier jet, extraire une information d’un ensemble mal rangé. Les cas d’usage qui tiennent partagent une caractéristique : quelqu’un relit le résultat et cette relecture coûte moins cher que le travail évité. Ceux qui déçoivent partagent l’inverse.

Support et relation client

Le cas qui tient est la préparation de réponse plutôt que la réponse automatique. Le modèle rassemble l’historique du dossier, la documentation applicable et propose un projet de message ; un humain valide et envoie. Le gain porte sur le temps de recherche, qui représente souvent l’essentiel du traitement d’un ticket, et non sur la rédaction.

Le cas qui déçoit est le robot conversationnel branché directement sur les clients sans période intermédiaire. Il fonctionne sur les demandes fréquentes et échoue précisément sur celles qui justifiaient un humain. Les organisations qui réussissent commencent par l’assistance interne aux agents et n’ouvrent au public qu’après avoir mesuré les écarts, une progression détaillée dans le guide sur l’automatisation du service client.

Marketing et contenu

Le cas qui tient est le travail sur de la matière existante : reformuler pour un autre public, produire des variantes, condenser des entretiens en points saillants. La matière première existe, le modèle la transforme, et la vérification est rapide parce que la source est sous les yeux.

Le cas qui déçoit est la production de contenu à partir de rien, à volume. Le résultat est correct et interchangeable, ce qui est le pire état possible pour un contenu destiné à distinguer une marque. La question de la visibilité dans les moteurs génératifs se pose d’ailleurs différemment de la visibilité classique, comme l’explique l’article sur la mesure de la visibilité d’une marque dans les réponses d’IA.

Opérations et back-office

C’est le domaine le plus rentable et le moins spectaculaire. Extraire des champs d’un document non structuré, comparer deux versions d’un contrat, classer des demandes entrantes, préparer un compte rendu à partir de notes. Chacune de ces tâches est petite ; leur addition représente une part importante du temps administratif.

La condition de réussite est la même partout : une sortie structurée et vérifiable. Une extraction que l’on peut contrôler d’un coup d’œil se déploie ; une synthèse en prose qu’il faut relire entièrement ne se déploie pas.

Le cas qui déçoit ici est la chaîne complètement automatisée sur des documents hétérogènes. Le taux d’erreur sur les cas simples est excellent, et il se dégrade sur les cas rares qui sont justement ceux qui coûtent. Il vaut mieux traiter automatiquement ce qui est reconnu avec certitude et router le reste vers un humain.

Technique

Deux usages sortent du lot. La compréhension d’une base de code que personne ne maîtrise plus, où la fenêtre de contexte étendue permet de soumettre un ensemble de fichiers plutôt qu’un fichier isolé. Et la rédaction de tests et de documentation, tâches utiles, fastidieuses, et faciles à vérifier.

L’usage qui demande plus de précaution est la connexion du modèle à des systèmes internes. Elle devient intéressante dès qu’il peut consulter une base ou déclencher une action, ce que la documentation d’Anthropic décrit sous le nom d’utilisation d’outils. Elle demande en contrepartie de décider explicitement ce que le système a le droit de faire, question de cadre plus que de technique.

Par quel cas d’usage commencer ?

Le meilleur premier cas réunit quatre propriétés : il est fréquent, il porte sur du texte, son résultat se vérifie en moins d’une minute, et une erreur n’a pas de conséquence irréversible.

Ce filtre élimine la plupart des idées séduisantes et laisse presque toujours une tâche de préparation ou d’extraction. C’est décevant en réunion et efficace en pratique, parce que ce premier cas sert surtout à apprendre à l’équipe ce que l’outil fait bien et mal.

Il vaut mieux aussi qu’il concerne une équipe volontaire. Un premier déploiement réussi dans une équipe demandeuse convainc plus sûrement qu’un déploiement imposé, et il produit les premiers repères partagés. Cette montée en compétence progressive relève d’une formation IA en entreprise par AI Makers autant que du choix technique.

Le cas d’usage qui déçoit presque toujours

L’assistant transversal, ouvert à toute l’entreprise, branché sur tous les documents, sans périmètre défini. Il séduit parce qu’il paraît résoudre tous les cas à la fois. Il échoue parce que sans périmètre, personne ne sait ce qu’il devrait savoir, et donc personne ne peut juger si sa réponse est bonne.

Les organisations qui y reviennent plus tard le font avec un périmètre restreint, une source documentaire maîtrisée et des règles claires sur ce qui entre. C’est le même mouvement que celui décrit dans l’article sur le déploiement de Claude dans une équipe : commencer petit n’est pas de la timidité, c’est la condition pour que quelqu’un puisse juger du résultat.