Déployer dans une équipe

Vous savez maintenant tout ce qu’il faut savoir pour utiliser Claude sérieusement. Ce dernier chapitre traite d’autre chose : faire passer une organisation de deux enthousiastes à un usage collectif qui produit un gain mesurable.

C’est un problème d’organisation, pas de technique. Et c’est là que la plupart des déploiements échouent.

Les trois façons d’échouer#

Elles sont remarquablement constantes.

Le déploiement par le haut. On achète des licences pour tout le monde, on annonce, on organise une formation d’une heure. Trois mois plus tard, 8 % des comptes sont actifs. L’outil est arrivé sans problème à résoudre.

Le déploiement par l’enthousiaste. Une personne devient très bonne, produit des résultats spectaculaires, et devient un goulot d’étranglement. Rien ne se transmet parce que rien n’est écrit. Cette personne part, et tout s’arrête.

Le déploiement par la peur. L’usage est encadré si strictement que plus personne ne l’utilise officiellement. Il continue sur les comptes personnels, sans cadre — exactement le risque qu’on voulait éviter. Voir le chapitre 35.

Le point commun : on a déployé un outil au lieu de déployer une façon de faire une tâche précise.

Commencer par une tâche, pas par l’outil#

Le premier cas d’usage détermine la suite. Quatre critères, cumulatifs.

Fréquent. Une tâche faite chaque semaine par plusieurs personnes. Un gain sur une tâche annuelle ne se voit pas.

Chronophage et peu gratifiant. Personne ne défend son droit à rédiger des comptes rendus.

À faible risque. Un travail interne, révisable, sans conséquence juridique immédiate. Le premier cas n’est pas le moment de tester la robustesse.

Vérifiable. On doit pouvoir dire si le résultat est bon, tout de suite, sans expertise particulière.

Des exemples qui remplissent les quatre : comptes rendus de réunion, réponses de premier niveau à des demandes récurrentes, synthèses de documents longs, mise en forme et relecture de livrables, préparation de trames.

Ce qu’il faut mutualiser#

C’est le cœur du sujet, et le point le plus mal traité dans la plupart des organisations. Trois niveaux.

Le contexte de travail : les Projects. Un Project par mission, par client, par produit, avec les documents de référence et les instructions permanentes. Toute personne qui rejoint la mission hérite du contexte. C’est le mécanisme de partage le plus rentable de tous — voir le chapitre 14.

La méthode : les Skills. Vos procédures internes, écrites une fois, disponibles pour tous. La structure de vos comptes rendus, vos règles de nommage, votre charte éditoriale, votre grille d’analyse d’appel d’offres. Une Skill transforme un savoir-faire individuel en capacité collective — voir le chapitre 17.

Les demandes validées : une bibliothèque interne. Pour chaque tâche récurrente, une demande qui marche, testée, avec un exemple d’entrée et de sortie. C’est ce que fait la bibliothèque de demandes de ce site, à l’échelle de votre organisation.

Ce qu’il ne faut pas mutualiser#

Les conversations individuelles. Personne ne veut lire les échanges des autres, et le partage systématique crée un sentiment de surveillance qui tue l’usage exploratoire — celui-là même dont on a besoin pour découvrir de nouveaux cas.

Le style de chacun. Deux personnes obtiennent le même bon résultat par des chemins différents. Imposer un chemin unique ne gagne rien et coûte de l’adhésion.

Former sans faire une formation#

Une session de deux heures pour trente personnes ne produit rien : les gens repartent sans problème à résoudre, et oublient en une semaine.

Quatre choses fonctionnent mieux, par ordre d’efficacité.

L’atelier sur cas réel. Six à huit personnes, chacune avec un vrai dossier en cours. Une heure. On traite le cas de chacun. Les gens repartent avec un résultat utilisable, pas avec des notes.

Le binôme. Une personne qui sait montre à une personne qui ne sait pas, sur le travail de cette dernière. Trente minutes. C’est le format le plus efficace, et le moins mis en place.

La demande type prête à l’emploi. Beaucoup de gens ne franchiront jamais le pas de la page blanche. Leur donner une demande à copier, qui marche, sur leur tâche, supprime cet obstacle.

La revue mensuelle courte. Trente minutes, un tour de table : qu’est-ce qui a marché, qu’est-ce qui a raté. Les échecs partagés valent les réussites — ils évitent que dix personnes butent sur le même mur.

Deux choses ne fonctionnent pas : la formation magistrale, et la documentation exhaustive écrite avant l’usage.

Mesurer l’adoption#

Le nombre de comptes actifs mesure la curiosité. Le volume de messages mesure l’agitation. Ni l’un ni l’autre ne mesure un gain.

Ce qui se mesure utilement.

Le nombre de tâches identifiées qui ont changé de méthode. C’est le seul indicateur qui compte vraiment. Trois tâches transformées valent mieux que quarante comptes actifs.

Le temps gagné sur ces tâches. Mesuré grossièrement, en demandant aux gens. Une estimation à la louche vaut mieux que rien, et personne ne vous demandera une étude.

Le taux de reprise. Sur les sorties utilisées, quelle proportion demande une correction lourde ? S’il est élevé, la méthode est mauvaise, pas l’outil — retour au chapitre 8.

Les cas d’usage nouveaux apparus spontanément. L’indicateur avancé le plus fiable. Quand des gens inventent des usages que vous n’aviez pas prévus, l’adoption est réelle.

Déployer sur une direction de cinquante personnes

La situation

Une direction marketing de cinquante personnes. Le directeur veut « déployer l’IA ». Deux chefs de projet utilisent déjà Claude quotidiennement, le reste n’a jamais essayé.

Ce qui a été refusé

Le plan initial — licences pour tout le monde, formation générale de deux heures, charte de dix pages. C’est le déploiement par le haut, et il aurait produit 8 % d’usage.

Le premier cas

Le brief agence. Rédigé quinze à vingt fois par mois, deux heures à chaque fois, structure toujours identique, faible risque puisqu’il est relu avant envoi, et qualité immédiatement vérifiable par quiconque connaît le métier.

Deux personnes l’essaient pendant trois semaines. Elles produisent une demande qui marche, après une douzaine d’itérations.

La mutualisation

Cette demande devient une Skill, avec la trame de brief maison et trois exemples de briefs réussis. Un Project « Briefs agence » contient la charte de marque, le positionnement produit et les briefs de l’année précédente.

À partir de là, n’importe qui dans l’équipe produit un premier jet correct sans savoir écrire une bonne demande. C’est le point de bascule : la compétence est passée de deux personnes à l’équipe.

L’extension

Deux ateliers d’une heure, huit personnes chacun, chacune avec un brief réel en cours. Pas de diaporama. À la fin de l’atelier, chacun a un brief utilisable.

En six semaines, quatre autres cas ont émergé, tous proposés par les participants et non par la direction : la synthèse des retours de tests consommateurs, la préparation de comités, la relecture de communiqués, la traduction de contenus marketing.

La mesure à trois mois

Cinq tâches ont changé de méthode. Le brief agence passe de deux heures à quarante minutes, relecture comprise — soit environ trente heures par mois sur l’ensemble de la direction.

Trente-deux personnes sur cinquante utilisent Claude au moins une fois par semaine. Le chiffre n’est pas l’objectif ; il est la conséquence.

Deux cas ont été abandonnés : la génération d’idées de campagne, où les résultats étaient génériques, et l’analyse de données de performance, où le tableur restait plus rapide. Documenter ces échecs a compté autant que documenter les succès — ils ont évité que d’autres réessaient.

Pour finir#

Vous avez parcouru trente-sept chapitres. Ce qu’il faut en retenir tient en peu de lignes.

Claude n’est ni un moteur de recherche, ni un oracle, ni un collègue. C’est un système qui prédit du texte, extraordinairement bon à cela, et dont les qualités et les défauts découlent tous du même mécanisme — c’était le chapitre 1, et tout le reste en découle.

La compétence qui compte n’est pas de connaître les fonctionnalités. C’est de savoir formuler, de savoir vérifier, et de savoir quand ne pas s’en servir.

Les produits évoluent, vite. Ce qui n’évolue pas : le contexte détermine la qualité, la spécificité bat la longueur, l’itération bat la formulation parfaite, et rien ne remplace une relecture humaine sur ce qui compte.

La page Repères porte la date de dernière vérification des faits de ce site. Quand elle sera vieille, méfiez-vous des chiffres — pas des méthodes.

Ce qu’il faut retenir#