Le test de réversibilité
Aussi en 28 langues
English · Español · 日本語 · Português (Brasil) · 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) · Français (Canada) · Deutsch (Schweiz)
Module 3 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 : Le modèle de données est l’ossature · Suivant : L’architecture est l’art des compromis
La question à laquelle répond ce module : comment distinguer une décision d’architecture d’une décision ordinaire ?
Les architectes prennent beaucoup de décisions.
Mais toutes les décisions ne sont pas des décisions d’architecture.
C’est une distinction importante. Si nous traitons chaque décision comme de l’architecture, nous passerons notre temps à débattre de choses relativement faciles à changer. Si nous ne reconnaissons pas les décisions qui sont vraiment d’architecture, nous pouvons prendre aujourd’hui en cinq minutes une décision qui prendra cinq ans à défaire.
Alors, comment faire la différence ?
J’aime poser une question simple :
À quel point sera-t-il difficile de revenir sur cette décision plus tard ?
J’appelle cela le test de réversibilité.
Plus une chose est difficile à défaire, et plus d’autres choses en dépendront, plus elle mérite d’attention architecturale.
Certaines décisions coûtent peu à changer
Section intitulée « Certaines décisions coûtent peu à changer »Commençons par quelque chose de simple.
Nous appelons un champ Customer Category (catégorie client). Six mois plus tard, le métier décide que tout le monde l’appelle en réalité Customer Segment (segment client). Nous changeons l’étiquette. Il y aura peut-être de la documentation à mettre à jour et un peu de formation des utilisateurs, mais ce n’est pas un événement d’architecture majeur. Nous devrons toutefois vivre avec le nom d’API d’origine, car le changer a des conséquences bien plus larges. Cela peut donc simplement vouloir dire gérer un changement d’étiquette, et la confusion qui peut l’accompagner.
Nous avons pris une décision. Nous avons changé d’avis. Nous sommes passés à autre chose.
Comparons maintenant avec une autre décision.
Nous créons un identifiant pour les clients. Nous décidons de ce qu’il signifie, de son format et du système qui le crée. Puis nous le publions.
Salesforce l’utilise. L’entrepôt de données l’utilise. La plateforme d’intégration l’utilise. Le portail client l’utilise. Cinq autres applications commencent à le stocker. Des rapports et des pipelines de données l’utilisent. Les clients finissent peut-être par le voir.
Trois ans plus tard, quelqu’un dit :
Nous n’aurions sans doute pas dû concevoir l’identifiant de cette façon.
C’est une conversation très différente.
La différence n’est pas qu’une décision est plus technique que l’autre.
La différence, c’est la réversibilité.
Voici comment cela peut arriver. Disons que l’entreprise construit ses clés à partir d’une partie du nom du client plus un numéro. Ça fonctionne pendant des années, parce que personne n’a jamais eu à changer de nom. Puis, un an ou plus tard, un nom change, et tout à coup les clés ne correspondent plus au modèle attendu par le reste des données. C’est l’une des raisons pour lesquelles une clé ne devrait porter aucune signification intrinsèque.
L’architecture crée de la gravité
Section intitulée « L’architecture crée de la gravité »Une décision d’architecture a tendance à accumuler des choses autour d’elle. Je pense à cela comme à de la gravité.
Choisissez un modèle d’objets, et l’automatisation se construit autour.
Choisissez une clé, et d’autres systèmes commencent à la stocker.
Choisissez où vivent les données de référence, et les intégrations commencent à circuler vers elles et à partir d’elles.
Choisissez un modèle de partage, et les processus métier commencent à dépendre de qui voit quoi.
Choisissez un modèle d’intégration, et les systèmes commencent à dépendre de son rythme et de son comportement.
Plus ces décisions existent longtemps, plus elles développent de gravité. À terme, changer la décision d’origine signifie changer tout ce qui s’est accumulé autour.
L’IA ressent aussi cette gravité. Un outil d’IA travaille à partir de ce qui est déjà dans le système : une fois qu’un élément de conception clé est là, chaque interaction avec l’IA qui suit le traite comme un fait et continue de construire dessus, et de construire dessus, et de construire dessus. La décision résonne à travers beaucoup d’autres décisions, et aucun humain ne revient jamais réexaminer l’originale. Chaque génération ajoute à la gravité.
C’est pourquoi le fait que le modèle de données soit « l’ossature » compte. Nous ne sommes pas prudents parce que le changement est mauvais. Nous sommes prudents parce que les dépendances rendent le changement coûteux.
Posez deux questions
Section intitulée « Posez deux questions »Quand j’examine une décision de conception, je pose deux questions :
À quel point est-ce difficile à défaire ?
Combien de choses vont en dépendre ?
Elles sont liées, mais pas identiques. Une chose peut être techniquement facile à changer mais avoir des centaines de consommateurs. On renommait autrefois les objets standard pour plus de clarté, par exemple le compte en « Client ». Facile à faire. Puis un autre système a voulu utiliser les comptes pour des partenaires, et ce n’était plus possible. Une autre chose peut n’avoir que quelques consommateurs mais exiger une migration énorme pour la changer, comme le nom d’API d’un objet référencé à de nombreux endroits en interne. Personne à l’extérieur ne le voit, mais un mauvais nom continue de semer la confusion dans l’équipe. Les deux méritent de l’attention.
Pensez à quelques décisions courantes sur les données :
- Quel objet Salesforce représente ce concept métier ?
- Quel est l’identifiant unique ?
- Quel système est le système d’enregistrement ?
- Ces données sont-elles copiées dans Salesforce ou consultées ailleurs ?
- Est-ce un seul objet ou plusieurs objets liés ?
- À qui appartiennent les données, et combien de temps les gardons-nous ?
- Quelles sont nos frontières d’accès par défaut ?
- Comment ces données circulent-elles entre les systèmes ?
C’est très différent de décider où un champ apparaît sur une page Lightning. La conception de page compte aussi. Mais le coût de l’erreur est différent.
Pensez au rayon d’impact
Section intitulée « Pensez au rayon d’impact »Une autre façon de penser la réversibilité est le rayon d’impact : si je change cette décision, qu’est-ce qui bouge d’autre ?
Supposons que quelque chose que nous avons modélisé comme un champ doive en réalité devenir un objet enfant. Ce n’est pas seulement un changement de schéma. Qu’arrive-t-il aux données existantes ? Aux rapports, aux intégrations qui attendent ce champ, à l’Apex et aux flows qui le référencent, à la sécurité, aux analyses, à un agent d’IA dont les actions dépendent de la structure d’origine ?
Plus le rayon est grand, plus nous devrions prendre la décision d’origine avec soin.
C’est aussi pourquoi les architectes doivent regarder au-delà de leur propre partie du système. Vu de l’intérieur de Salesforce, un changement peut paraître facile. Vu de l’entreprise, il peut toucher douze autres systèmes.
Décisions d’entreprise et décisions Salesforce
Section intitulée « Décisions d’entreprise et décisions Salesforce »Un architecte de données pense à deux niveaux.
Dans Salesforce, nous décidons des objets, des relations, des clés, du volume, de l’accès, de l’automatisation, et de la façon dont les données se comportent sur la plateforme.
À l’échelle de l’entreprise, nous posons des questions plus larges. Où vit réellement le client ? À qui appartient le produit ? Quel système crée une commande ? Quel est notre identifiant de référence ? Quelles informations sont copiées entre les systèmes, et lesquelles restent où elles sont ?
Les deux niveaux doivent se rejoindre. J’ai vu des mises en œuvre Salesforce où le modèle interne était parfaitement logique en lui-même mais ne s’accordait pas avec l’entreprise autour. Ce n’est pas suffisant. Les structures Salesforce doivent être représentées au niveau de l’entreprise, et les décisions d’entreprise doivent redescendre dans Salesforce.
L’architecture est une circulation à double sens.
Ralentissez sur les décisions coûteuses
Section intitulée « Ralentissez sur les décisions coûteuses »L’un des dangers de la technologie, c’est que les décisions les plus faciles à mettre en œuvre peuvent ressembler aux décisions les plus faciles à prendre. Ce n’est pas la même chose.
Créer un autre objet personnalisé est facile. Créer un autre champ est facile. Connecter une autre API devient de plus en plus facile, et l’IA rend tout cela encore plus facile.
Mais la facilité de mise en œuvre ne nous dit presque rien du coût de la décision d’architecture.
Avant une décision difficile à défaire, ralentissez assez longtemps pour vous demander : quel problème résolvons-nous réellement ? Quelles options avons-nous envisagées ? Que supposons-nous ? Que se passe-t-il quand le volume grandit, et quand le métier change ? Qu’est-ce qui d’autre va en dépendre ? Que se passe-t-il si nous avons tort ?
Nous n’avons pas besoin de six mois de revue à chaque fois que nous créons un objet. Nous avons besoin d’une réflexion proportionnée au coût de l’erreur. S’il s’agit d’un objet pour un seul service ou sous-système, vous pouvez avancer plus vite. S’il s’agit de données de référence, d’un objet client clé ou de quelque chose d’utilisé entre plusieurs systèmes, prenez le temps d’y réfléchir.
Écrivez pourquoi
Section intitulée « Écrivez pourquoi »Il y a un autre problème avec les décisions importantes : les gens oublient pourquoi elles ont été prises.
Quelqu’un regarde une architecture trois ans plus tard et demande : « Pourquoi diable quelqu’un aurait-il conçu ça comme ça ? » Parfois, la réponse est que c’était une mauvaise conception. Ça arrive. Mais parfois, il y avait une très bonne raison : une limite de la plateforme qui n’existe plus, une exigence réglementaire, un autre système qui ne pouvait pas prendre en charge l’approche préférée, un compromis accepté sciemment pour tenir une échéance.
Si nous ne consignons que ce que nous avons décidé et non pourquoi, l’architecte suivant n’a aucun moyen de le savoir.
Pour les décisions importantes, écrivez-le. Pas besoin d’un document de 50 pages. Un registre de décision utile peut être très court :
Contexte : quel problème résolvons-nous ?
Options : quelles options réalistes avons-nous envisagées ?
Décision : qu’avons-nous choisi ?
Conséquences : que gagnons-nous, et à quoi renonçons-nous ?
Responsable : qui répond de cette décision ?
Révision : quelle raison ou quelle date devrait nous la faire réexaminer ?
La valeur n’est pas dans le document. La valeur, c’est de préserver le raisonnement.
Et quand une décision change, n’effacez pas l’originale. Remplacez-la. La décision qui était juste en 2027 ne l’est peut-être plus en 2030, parce que les volumes, le métier, Salesforce et notre compréhension changent tous. Ce que je veux garder, c’est l’histoire : voici le contexte, voici la décision et pourquoi, voici ce qui a changé, et voici ce que nous décidons maintenant. C’est bien plus précieux que de prétendre que nous avons toujours connu la réponse.
Au-delà de l’examen : l’IA raccourcit le temps entre la décision et la dépendance. Un outil d’IA peut proposer un modèle de données en quelques secondes, puis créer par-dessus les objets, l’automatisation, le code d’intégration et l’interface utilisateur. Une décision discutable demandait autrefois des mois de développement avant que beaucoup de choses en dépendent ; maintenant, les dépendances arrivent presque aussitôt. Revoyez donc les décisions sous le résultat, pas seulement le résultat. L’IA peut aider : elle peut lister des options, remettre en cause des hypothèses et rédiger le registre de décision. Mais l’architecte décide toujours, et plus la décision est difficile à défaire, plus ce jugement humain compte.
Sachez quelles décisions comptent
Section intitulée « Sachez quelles décisions comptent »L’une des compétences que je veux vous voir développer, c’est savoir où porter votre attention.
Ne transformez pas chaque choix de configuration en sommet d’architecture.
Mais ne prenez pas à la légère une décision avec laquelle l’organisation vivra pendant les dix prochaines années.
Demandez-vous :
À quel point sera-t-il difficile de revenir en arrière ?
Combien de choses vont en dépendre ?
Si les réponses sont très difficile et beaucoup, vous avez probablement trouvé une décision d’architecture.
Ralentissez. Comprenez l’exigence. Explorez les options. Rendez les compromis visibles. Prenez la décision. Et écrivez pourquoi.
Le but de l’architecture n’est pas de prendre des décisions qui ne pourront jamais changer.
Le but est de reconnaître les décisions pour lesquelles changer d’avis coûtera cher.
Ce que l’architecte décide ici
Section intitulée « Ce que l’architecte décide ici »- Quelles décisions sont d’architecture : difficiles à défaire, avec beaucoup de choses qui en dépendent.
- Combien d’attention reçoit chaque décision, en proportion du coût de l’erreur.
- Quelles décisions sont consignées, avec leur contexte, leurs options, leurs conséquences, leur responsable et leur point de révision.
- Comment les décisions Salesforce s’alignent sur celles de l’entreprise.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Object Relationships Overview (opens in a new tab), aide Salesforce (en anglais, consulté le 2026-10-09 ; revérifié le 2026-10-12) : dans une relation principal-détails, l’accès et la propriété de l’enregistrement de détail suivent le principal, et supprimer un principal supprime ses détails.
- Considerations for Object Relationships (opens in a new tab), aide Salesforce (en anglais, consulté le 2026-10-09 ; revérifié le 2026-10-12) : une relation de référence ne se convertit en principal-détails que si chaque enregistrement y a une valeur ; la conversion change le modèle de partage (en Contrôlé par le parent), et le type de relation détermine quels types de rapport standard sont disponibles.
- Roll-Up Summary Field (opens in a new tab), aide Salesforce (en anglais, consulté le 2026-10-09 ; revérifié le 2026-10-12) : les champs de récapitulatif de cumul n’existent que sur les relations principal-détails, et doivent être supprimés avant qu’une relation principal-détails puisse redevenir une relation de référence.