Salesforce et l'IA : quand la maîtrise devient personnelle

Concevoir comment les designers maîtrisent l'IA

Maîtriser un outil d'IA ne consiste pas simplement à apprendre son utilisation correcte. Il s'agit d'apprendre à l'adapter à votre façon de penser — et ce type de maîtrise est personnel, divergent et jamais terminé.

Chaque designer reçoit des instructions pour utiliser des outils d'IA. Peu d'entre eux savent réellement ce que cela signifie de maîtriser un tel outil. Et sous-jacent à cela se trouve une question que presque personne n'ose formuler à voix haute lors de l'intégration des outils : si ces outils deviennent suffisamment performants, que va-t-il advenir des emplois ?

La plupart des organisations tentent de résoudre ces trois problèmes avec un seul plan de formation. Cela ne fonctionne pas. Les designers avec qui je travaille ressentent une excitation et une anxiété à peu près égales, souvent dans le même moment. Ils ont entre les mains une catégorie d'outils qui ne se comportent pas comme les logiciels auxquels ils sont habitués, et la réponse conventionnelle — rédiger une présentation, organiser un atelier, déclarer la maîtrise — continue de produire le même résultat : une salle pleine de personnes qui se sentent en retard, même lorsqu'elles essaient de progresser.

Cet essai traite de ce qui s'est passé lorsque mon équipe a cessé d'essayer de résoudre le problème de cette manière. Et il aborde le mot maîtrise lui-même — que je ne veux pas abandonner. Je veux le redéfinir.

Une nouvelle approche

Le 1er octobre 2025, dix-huit personnes étaient en visioconférence, quelques minutes avant neuf heures du matin PST. Je veux commencer ici car ce que Fatimah Richmond a ouvert lors de cette session a fait quelque chose que j'attendais depuis presque un an.

Elle a dit : « Je ne suis pas une experte. »

Elle l'est, bien sûr. Juste pas dans le sens qui compte ici. Personne ne l'est. C'est tout l'enjeu. Fatimah — chercheuse UX, poétesse publiée, vingt ans dans la vallée, avec DeepMind sur son CV — avait rejoint l'équipe UX Service de Salesforce au début de l'année, sortant d'un monde où Gemini était l'outil par défaut pour presque tout. Elle apporte l'instinct d'un chercheur pour la gestion des connaissances et une relation territoriale de conteuse avec la voix des participants. Elle était exactement la bonne personne pour ouvrir notre série — non pas parce qu'elle avait des réponses, mais parce qu'elle avait construit discrètement une pratique personnelle que personne d'autre dans l'équipe n'avait encore.

L'outil qu'elle s'apprêtait à nous montrer était NotebookLM, un produit de Google pour synthétiser de grandes quantités de documents. Elle l'avait utilisé pour faire ressortir des insights provenant d'années de recherches accumulées chez Salesforce — des études réalisées par des personnes qui étaient depuis parties, des connaissances vivant dans des documents que personne n'ouvre plus. Elle l'appelait « le carnet intelligent ». Ce n'était pas le nom de Google. C'était le sien. Un modèle mental qu'elle avait développé elle-même, de son point de vue particulier.

C'était la première session d'une série de co-apprentissage qui allait durer six mois pour l'équipe UX Service chez Salesforce — quarante-six designers aux États-Unis, en Inde et en Israël, tous essayant de comprendre la même chose : que faire avec ces outils qui arrivent plus vite que nous ne pouvons les assimiler ?

Ningdan Zhang — designer produit senior et mon co-facilitateur — et moi avons conçu la série ensemble. Ce changement de perspective est important dès le départ, car il modifie ce dont traite cet essai. Nous avons créé la structure ensemble, l'échafaudage session par session, l'instinct de ce dont l'équipe avait besoin semaine après semaine. Nous avons apporté l'hypothèse et l'arc narratif. Aucun de nous ne savait si cela fonctionnerait. Ce n'est pas un retour d'expérience. C'est une étude de cas de design — qui a commencé avec une question partagée, a duré six mois et a produit une découverte que je n'attendais pas.

Un paradoxe à résoudre

Le problème pour lequel nous concevions avait une forme spécifique. Les designers de l'équipe ressentaient un paradoxe : une excitation réelle pour les outils d'IA, accompagnée d'une anxiété significative quant à ceux à utiliser, quand et comment. En dessous de cela, la question plus discrète de savoir quels emplois pourraient ne pas exister dans deux ans. Les annonces arrivaient rapidement. Les conseils structurés étaient écrasants ou manquants. Chacun essayait de s'en sortir de manière indépendante — efforts dupliqués, flux de travail incohérents, pression pour avoir un prototype codé par l'ambiance à montrer sans aucune base partagée sur la manière de le construire.

Notre hypothèse était simple, peut-être naïve : que se passerait-il si nous apprenions simplement les uns des autres ? Deux sessions de trente minutes par mois. Un outil, un travail à réaliser, une session d'initiation approfondie sur un outil, une personne prête à partager ce qu'elle avait réellement compris — de manière imparfaite, en cours de route, sans avoir besoin d'avoir la réponse. Nous avons couvert tout ce que l'équipe demandait : NotebookLM, Slack AI, Cursor, espaces de projet (Claude, Gemini Gems, OpenAI), outils du système de design Salesforce, Figma Make, Wispr Flow.

Ce que nous n'avions pas anticipé, c'était ce que le format révélerait sur la nature des outils eux-mêmes — et sur ce que signifie réellement les maîtriser.

Une erreur de catégorie

Il y a une erreur de catégorie qui se produit lorsque les organisations essaient d'enseigner les outils d'IA de la même manière qu'elles enseignent d'autres logiciels. La formation traditionnelle sur les logiciels fonctionne parce que les outils sont déterministes. Vous apprenez où se trouvent les boutons, ce que font les raccourcis, comment le système se comporte lorsque vous cliquez sur quelque chose. La maîtrise, dans ce monde, converge — tout le monde atteint à peu près la même compétence, en suivant à peu près le même chemin, et vous pouvez rédiger une présentation pour cela. La maîtrise signifie connaître l'utilisation correcte de l'outil.

Les outils d'IA brisent cette définition. Maggie Appleton — designer et anthropologue, maintenant chez GitHub Next — a donné une conférence en 2023 intitulée « Squish Meets Structure » sur la conception de produits avec des modèles linguistiques, et la phrase que j'adore est sa description de la boîte d'entrée magique : elle n'a « aucune affordance », « aucun bouton ni poignée de porte ». L'interface, écrit-elle, « décharge une tonne de travail cognitif sur l'utilisateur ». Il n'y a pas d'utilisation correcte à apprendre. L'outil vous rencontre là où vous êtes. Ce que vous apportez — vos instincts, vos modèles mentaux, votre goût accumulé, votre volonté d'itérer, vos fichiers personnalisés claude.md — fait partie de l'outil, tout autant que le modèle.

Ainsi, la maîtrise n'a pas disparu. Elle a changé. Avec les logiciels déterministes, maîtriser l'outil signifiait converger vers sa logique. Avec les outils d'IA, maîtriser un outil signifie le contraire : apprendre à l'adapter à votre logique. L'adapter à la manière dont vous souhaitez déjà travailler. Maîtriser un outil d'IA est l'art de le faire amplifier les forces et l'expérience spécifiques que vous apportez — afin que le travail produit soit plus précis et indubitablement le vôtre. Ce type de maîtrise est réel, difficile à acquérir et mérite d'être enseigné. Il est simplement personnel plutôt qu'universel. Divergent plutôt que convergent. La version de chacun devrait être différente, car la version de chacun est construite à partir d'une personne différente.

C'est ce que la plupart des plans de formation se trompent. Ils visent les designers vers l'ancienne forme de maîtrise — une compétence unique, ratifiée par un cursus — alors que ce qui vaut réellement la peine d'être atteint est la nouvelle forme. Et la nouvelle forme ne peut pas être transférée par une présentation. Les mandats descendantes échouent non pas parce que les designers sont résistants, mais parce que vous ne pouvez pas donner à quelqu'un une bonne relation avec un outil d'IA. Vous ne pouvez créer que des conditions dans lesquelles ils construisent la leur.

Cela ne remet pas en question le soutien institutionnel. C'est un argument en faveur de deux couches travaillant en tandem. L'équipe UX Ops de Salesforce fait un travail essentiel qu'une série de pairs comme la nôtre ne pourrait jamais faire : approuver les outils, gérer la gouvernance, déployer des modules d'apprentissage et des hackathons, naviguer dans les budgets de jetons, débloquer l'accès. Ils ont construit l'infrastructure nécessaire — l'échafaudage qui rend l'échelle possible. Sans cela, les expériences individuelles restent isolées. Mais le type de connaissance que Fatimah s'apprêtait à partager — qui vit dans une session de trente minutes où un collègue vous montre ses véritables carnets, ses solutions de contournement, ses architectures d'information personnelles, la chose qu'elle a essayée et qui n'a pas fonctionné — ne peut pas vivre dans un module. La couche de pairs est celle où la maîtrise, le type personnel, se transmet réellement. Les deux sont nécessaires. Aucun ne remplace l'autre.

Retour à Fatimah

Ce qui rendait sa session digne d'intérêt n'était pas l'outil. C'était la maîtrise qu'elle avait construite autour de celui-ci — exactement le type personnel. Elle avait appris, par essais et erreurs, qu'il ne suffit pas de tout mettre — le carnet nécessite une curation, des sources parlant le même langage, des sujets alignés afin que le moteur de raisonnement ne « parle pas à quelqu'un qui s'égare ». Elle avait ajouté des onglets de résumé aux transcriptions des participants, non pas parce qu'un tutoriel lui avait dit de le faire, mais parce que la transcription brute était trop désordonnée, trop humaine. Elle avait découvert que la fonctionnalité audio était peu fiable pour son cas d'utilisation — la synthèse de recherche où le ton compte, où les mots exacts d'un participant ont du poids — mais pouvait bien fonctionner pour intégrer un nouveau partenaire dans trois ans de connaissances accumulées.

Rien de tout cela ne provenait de la documentation. Cela venait d'elle — de vingt ans de pratique en recherche, de l'instinct d'une conteuse pour protéger la voix des participants, du besoin d'un chercheur de curer avant d'analyser. L'outil était le même que tout le monde avait à sa disposition. Ce qu'elle avait construit avec était le sien. Elle avait pris un instrument générique et l'avait adapté, précisément, pour affiner le travail qu'elle savait déjà faire.

Aditi Sharma, une designer produit senior de l'équipe, a nommé ce que nous étions tous en train de regarder sans vraiment le voir. Dans l'enquête post-mortem, elle a écrit que ce qu'elle appréciait dans ces sessions était « une fenêtre sur la pensée de quelqu'un ». Cette phrase est toute la découverte. Lorsque tout le monde utilise les mêmes boutons, regarder un collègue travailler est informatif mais pas révélateur. Lorsque la maîtrise est personnelle — lorsque le même outil produit des travaux radicalement différents en fonction de qui le manie — regarder quelqu'un l'utiliser bien devient une fenêtre sur sa façon de penser.