Connaître ses outils : les neuf questions

🌐 Aussi en 28 langues

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Deutsch (Schweiz)

Image générée par IA

Traduit par IA. Pas encore relu par la communauté. Lire en anglais

Module 6 sur 7 du chapitre Penser comme un architecte de données, le premier chapitre du cours Data Architect. Chaque module se suffit à lui-même. Précédent : Construire pour aujourd’hui. Prévoir demain. Prévoir l’échec. · Suivant : L’architecte de données à l’ère de l’IA

La question à laquelle répond ce module : comment évaluer n’importe quel outil, y compris un outil que vous n’avez jamais vu ?

Les architectes ont besoin de jugement. Mais le jugement sans connaissance ne sert pas à grand-chose. Il faut quand même connaître ses outils.

Je forme des architectes depuis des années, et l’un des cadres que j’utilise est une série de questions auxquelles vous devriez pouvoir répondre pour chaque outil ou fonctionnalité important de votre architecture. J’enseignais à l’origine huit questions. J’en ai ajouté une neuvième. Les technologies changent, Salesforce change, de nouveaux produits apparaissent et d’anciennes fonctionnalités évoluent, et l’IA accélère tout cela. Ces questions continuent de fonctionner.

Les neuf questions

Chaque fois que vous apprenez ou évaluez une technologie, demandez-vous :

1. Qu’est-ce que c’est ?
2. Où l’utilise-t-on ?
3. Comment l’utiliser ?
4. Quelles sont mes alternatives ?
5. Quelles sont ses forces ?
6. Quelles sont ses faiblesses ?
7. Comment l’expliquer aux développeurs, au métier et aux dirigeants ?
8. Comment est-il maintenu sur le long terme ?
9. Combien coûte-t-il, quelles licences exige-t-il, et quelles sont ses limites ?

Si vous pouvez répondre aux neuf, vous commencez à comprendre l’outil comme un architecte. Remarquez ce qui n’est pas sur la liste : « Est-ce que je sais le configurer ? » Cela compte, mais ce n’est qu’une partie de la connaissance de l’outil.

Click to enlarge

1. Qu’est-ce que c’est ?

Commencez par la question évidente, car on la saute étonnamment souvent. Nous entendons le nom d’un produit ou d’une fonctionnalité et commençons aussitôt à discuter de son utilisation. Ralentissez. Que fait-il réellement ? Quel problème a-t-il été conçu pour résoudre ? Où se situe-t-il dans l’architecture, et que n’est-il pas ? Un architecte devrait pouvoir décrire une technologie sans répéter le discours marketing. Si je ne peux pas expliquer quelque chose en quelques phrases, c’est probablement que je ne le comprends pas encore assez bien.

2. Où l’utilise-t-on ?

Savoir ce que fait une chose n’est pas la même chose que savoir quand elle a sa place dans une architecture. Pour quels types de problèmes est-elle bonne ? Quelles conditions la rendent appropriée, et quelles conditions devraient me rendre méfiant ? C’est le passage de « je connais cette fonctionnalité » à « je reconnais le problème que cette fonctionnalité résout », et c’est un grand pas. Vous ne voulez pas vous promener à la recherche d’endroits où utiliser votre technologie préférée. Vous voulez reconnaître des problèmes et savoir quels outils y répondent.

3. Comment l’utiliser ?

Oui, les architectes doivent comprendre la mise en œuvre. Vous n’avez pas à construire chaque composant, mais vous devez en comprendre assez pour savoir ce que vous demandez aux autres de construire. Sachez comment on le configure, comment un développeur travaille avec, comment les données entrent et sortent, comment on le déploie et le sécurise, et à quoi il ressemble en exploitation. Je ne veux pas d’un architecte qui conçoit autour d’une technologie qu’il n’a vue que sur une diapositive produit. Mettez les mains dedans : construisez quelque chose, cassez quelque chose, voyez comment ça se comporte vraiment. L’architecture s’améliore quand elle est ancrée dans la réalité.

4. Quelles sont mes alternatives ?

C’est peut-être la question la plus importante de la liste. Si vous ne connaissez qu’une seule façon de résoudre un problème, vous n’avez pas de décision d’architecture ; vous avez un choix par défaut. Chaque fois que quelqu’un propose une technologie, je veux savoir ce que nous pourrions faire d’autre. Une autre fonctionnalité Salesforce ? Quelque chose de déclaratif, ou du code ? La fonctionnalité pourrait-elle vivre hors de Salesforce ? Pourrions-nous laisser les données là où elles sont au lieu de les copier, utiliser un événement au lieu d’un appel d’API, ou éviter de construire quoi que ce soit ? Les alternatives créent des compromis, et les compromis sont le cœur de l’architecture.

5. Quelles sont ses forces ?

Chaque outil existe pour une raison. Comprenez ce pour quoi il est vraiment bon : ce qu’il rend facile, où il passe bien à l’échelle, quelle complexité il supprime, quels problèmes il résout élégamment. Utilisez les technologies là où leurs forces correspondent au problème. Cela paraît évident, mais il est très facile de choisir un outil parce que nous le possédons déjà, que l’équipe le connaît, qu’il est nouveau, ou que quelqu’un a vu une démo. Ce peuvent être des facteurs. Ce n’est pas la même chose que l’adéquation architecturale.

6. Quelles sont ses faiblesses ?

C’est tout aussi important. Chaque technologie a des faiblesses, toutes. Si quelqu’un ne peut vous citer que les forces d’une technologie, vous n’avez pas encore de discussion d’architecture. Qu’est-ce qu’elle fait mal ? Où apparaît la complexité, et que se passe-t-il à grande échelle ? Quelle charge d’exploitation et quelles dépendances apporte-t-elle ? Quelles exigences la sortent de son domaine de prédilection ? Une faiblesse ne veut pas toujours dire que nous ne devons pas utiliser la technologie. Cela veut dire que nous devons savoir ce que nous acceptons. Un compromis que vous comprenez peut être une décision d’architecture. Un compromis que vous ne comprenez pas peut devenir une surprise.

7. Comment l’expliquer à différents publics ?

C’est l’une des questions qui séparent la connaissance technique de la compétence d’architecte. Pouvez-vous expliquer la même technologie à un développeur, au métier et à un dirigeant ? Ce ne devraient pas être les mêmes explications. Le développeur a besoin des API, du comportement transactionnel, de la sécurité, de la gestion des échecs et des modèles de mise en œuvre. Le métier s’intéresse à ce que cela permet et à la façon dont son processus change. Le dirigeant s’intéresse au coût, au risque, au délai, à l’impact sur l’organisation, et aux options que la décision garde ouvertes ou ferme. Vous ne changez pas la vérité ; vous changez le niveau d’abstraction. Si la seule façon d’expliquer une technologie est le vocabulaire de sa documentation, continuez de travailler votre compréhension.

8. Comment est-il maintenu sur le long terme ?

Les projets se terminent. Les systèmes, non, ou du moins nous l’espérons. Quelqu’un doit prendre en charge ce que nous construisons une fois l’équipe projet partie. Cela veut dire savoir comment on le surveille, le met à niveau et le dépanne, qui doit avoir les compétences pour le soutenir, comment les changements sont déployés et testés, et ce qui se passe quand la technologie évolue ou que Salesforce change quelque chose sous nos pieds. Imaginez-le dans trois ans. J’ai vu des architectures très astucieuses le jour du lancement et pénibles à exploiter ensuite. Ce n’est pas un succès. La maintenabilité fait partie de l’architecture.

9. Combien coûte-t-il, quelles licences exige-t-il, et quelles sont ses limites ?

C’est la question que j’ai ajoutée aux huit d’origine, et aujourd’hui je pense qu’on ne peut plus l’omettre. Une technologie peut être la solution technique parfaite et pourtant la mauvaise solution d’architecture si l’économie ne fonctionne pas. Est-elle incluse dans nos licences, ou est-ce une option ? Est-elle facturée par utilisateur, à l’usage, à la consommation, au stockage ou à la transaction ? Qu’arrive-t-il au coût quand nous passons à l’échelle ?

Ensuite, il y a les limites, et chaque plateforme en a : limites d’API, de stockage, de requêtes, de transactions, de concurrence, de débit et de licences. Certaines sont strictes, d’autres souples ; certaines peuvent être relevées et d’autres non ; certaines ne comptent pas à notre échelle jusqu’à ce que nous ajoutions un zéro. Vous n’avez pas à mémoriser toutes les limites de Salesforce, et ce serait un très mauvais usage de votre temps. Vous devez savoir que les limites existent, lesquelles comptent pour votre architecture, et quand aller vérifier le chiffre actuel. Les chiffres changeront. La question d’architecture demeure.

Un exemple concret : le partage Apex

Voici l’un de mes exemples les plus fréquents des questions à l’œuvre. Nous recevons une exigence de partage compliqué, un partage qu’aucune règle de partage basée sur le propriétaire ou sur des critères ne permet de satisfaire. Cela nous mène au partage Apex : du code qui écrit lui-même les enregistrements de partage. Il nous faut donc savoir ce qu’est le partage Apex, où on l’utilise, comment l’utiliser, et le reste. C’est une escalade : le partage Apex est l’alternative (question 4) quand les règles dont nous avons besoin dépassent ce que le partage basé sur le propriétaire ou sur des critères peut exprimer.

Maintenant ses faiblesses (question 6). Disons que nous avons une communauté clients de 10 ou 20 millions de membres, et que nous utilisons la licence Customer Community, pas Customer Community Plus. Ce sont des utilisateurs à volume élevé. Ils n’ont pas de rôle, et n’utilisent pas du tout le modèle de partage : leur accès vient des ensembles de partage et des groupes de partage, rapprochés via leur compte et leur contact. Il n’y a aucun enregistrement de partage qu’Apex pourrait écrire pour eux, donc le partage Apex ne fonctionne pas pour eux. Et c’est la question du coût et des licences (question 9) qui nous a menés là : le choix de licence a décidé quels outils de partage existent tout court.

Donc, de même que le partage Apex était l’alternative aux règles basées sur le propriétaire et sur des critères, vous pouvez tomber sur un cas où il vous faut une alternative au partage Apex. Et à ce stade, il n’existe pas vraiment d’option par configuration pour des règles de partage complexes. Vous finissez par rendre l’objet en lecture seule et par contrôler l’accès via Apex. C’est pourquoi on pose les neuf questions avant de choisir, pas après.

N’apprenez pas la plateforme par cœur

C’est ce qui compte le plus quand vous apprenez l’architecture Salesforce. N’essayez pas d’apprendre Salesforce par cœur. Vous ne pouvez pas : la plateforme est trop vaste et change trop vite. Je travaille avec Salesforce depuis longtemps, et j’apprends encore. C’est normal.

Ce que je veux vous voir développer, c’est un cadre pour apprendre. Quand Salesforce sortira une nouvelle fonctionnalité demain, je n’ai pas besoin de l’avoir déjà vue. Je sais quoi demander : qu’est-ce que c’est, où ça se place, comment l’utiliser, que pourrais-je utiliser d’autre, en quoi c’est bon, où ça peine, comment l’expliquer, comment l’exploiter, combien ça coûte et où sont les limites ? Maintenant je peux commencer à l’évaluer. C’est bien plus précieux que d’apprendre par cœur une matrice de fonctionnalités de plus.

Au-delà de l’examen : l’IA rend les neuf questions plus rapides à répondre, et plus faciles à rater. Face à une technologie que vous ne connaissez pas, vous pouvez demander à l’IA de l’expliquer, de comparer trois approches, de lister ses limites et ses modes d’échec courants, ou de plaider contre son utilisation. C’est un assistant de recherche remarquable. Mais il peut se tromper, être dépassé, ou confondre avec assurance deux produits ou éditions aux noms proches. Pour tout ce qui influence une décision, vérifiez : suivez la source et consultez la documentation, les limites et les licences actuelles. Faire confiance, mais vérifier (module 7).

Apprenez les questions, pas seulement les réponses

Nous rencontrerons beaucoup de technologies dans ce cours. Je ne veux pas que vous collectionniez des réponses ; je veux que vous pratiquiez les questions. Quand nous parlerons des big objects, des données externes, de Data 360, des modèles d’intégration, ou d’une fonctionnalité d’IA que Salesforce sortira six mois après l’écriture de ce chapitre, posez les mêmes neuf questions.

Les réponses changeront. Les questions durent. C’est ce qui fait de ceci un cadre d’architecture plutôt qu’un guide de révision.

Connaissez vos outils : ce pour quoi ils sont bons, ce pour quoi ils sont mauvais, ce que vous pourriez utiliser d’autre, ce qu’ils coûtent et où ils cassent. Et sachez-en assez pour expliquer la décision à ceux qui devront vivre avec. C’est ainsi qu’un architecte apprend la technologie.

Ce que l’architecte décide ici

• Si un outil correspond au problème, jugé sur les neuf questions, pas seulement sur la possibilité de le configurer.
• Quelles sont les alternatives, et ce que le coût, les licences et les limites de l’outil signifient à votre échelle.
• Qui le maintiendra, et comment, dans trois ans.
• Quels faits sur l’outil vérifier avant de s’y fier.

Pour aller plus loin

• About High-Volume Community or Site Users (opens in a new tab), aide Salesforce (en anglais, consulté le 2026-10-09 ; revérifié le 2026-10-12) : les utilisateurs à volume élevé (les licences External Apps, Customer Community, High Volume Customer Portal et Authenticated Website) n’ont pas de rôle ; leur accès vient des ensembles de partage et des groupes de partage ; ils ne peuvent pas être inclus dans les règles de partage basées sur le propriétaire, et les enregistrements qu’ils possèdent ne peuvent pas être partagés manuellement.
• Platform Sharing Architecture (opens in a new tab), Salesforce Architects (en anglais, consulté le 2026-10-09 ; revérifié le 2026-10-12) : les utilisateurs à volume élevé (Customer Community, High Volume Customer Portal, Authenticated Website) n’utilisent pas le modèle de partage, parce que leurs licences ne prennent pas en charge les rôles ; l’accès fonctionne en rapprochant l’utilisateur des références vers le compte et le contact, via des ensembles de partage ou des groupes de partage. La même page indique quand le partage géré par Apex est le bon outil.
• Account Sharing Sets for High Volume Customer Portal Users (opens in a new tab), question de la Trailblazer Community, novembre 2024 (en anglais, consulté le 2026-10-09 ; revérifié le 2026-10-12) : un praticien signale que l’insertion d’enregistrements de partage pour des utilisateurs à volume élevé a échoué avec une erreur. Un retour de terrain, pas une documentation officielle. (La Trailblazer Community en ligne passe en lecture seule le 30 octobre 2026 ; le lien pourrait changer.)
• Create a Sharing Set for Experience Cloud Site Users (opens in a new tab), aide Salesforce (en anglais, consulté le 2026-10-09) : un ensemble de partage donne accès aux enregistrements liés au compte ou au contact de l’utilisateur.