Une org Salesforce d’entreprise peut tourner des années sur du code imparfait. Elle se fige quand plus personne ne sait dire qui décide. Une matrice RACI et un comité des changements trimestriel ne règlent pas la question. La gouvernance doit dire où se trouve l’autorité, comment chaque changement est classé, et qui tranche quand deux responsables ne sont pas d’accord.
Quand elle manque, les dégâts prennent la forme d’une dérive plutôt que d’un incident : configuration parallèle, intégrations non documentées, business units qui écrasent les métadonnées des autres, et une plateforme plus difficile à faire évoluer à chaque release.
Des droits de décision à trois niveaux
L’autorité doit être explicite à trois niveaux.
- Niveau plateforme : stratégie de l’org, cadence de release, standards, modèle de sécurité et de partage. Un petit groupe, avec une personne nommée qui peut dire non.
- Niveau domaine : le responsable d’un cloud, ou de la configuration d’une business unit.
- Niveau changement : qui approuve chaque catégorie de changement, et dans quel délai.
Réunissez les trois dans une seule file d’approbation et vous obtenez un goulot d’étranglement que les équipes apprennent à contourner. C’est ainsi que naît le développement fantôme. Une gouvernance qui n’existe que pour refuser se fait contourner. Celle qui fait du chemin sûr le chemin le plus court est suivie.
Le chemin d’escalade compte autant que les niveaux. Quand deux responsables de domaine s’opposent sur un objet partagé, le niveau plateforme tranche, et le délai de cette décision est écrit.
Sur le delivery Service Cloud de L’Occitane Group pour le Japon et la France (2023-2024), les changements venus du siège et des équipes APAC passaient par un seul circuit de validation. Le mécanisme est simple. Avec un circuit unique, une demande du siège et une demande d’une équipe APAC sont classées avec les mêmes questions et partent dans la même release. Avec deux circuits, chaque côté se croit propriétaire des objets partagés, et le conflit apparaît en production.
Des niveaux de changement selon le périmètre d’impact
Classez les changements selon ce qu’ils peuvent casser. Le demandeur et l’urgence ressentie n’entrent pas en ligne de compte.
| Niveau | Périmètre | Exemples | Approbation |
|---|---|---|---|
| Risque plateforme | Infrastructure partagée, intégrations inter-org, modèle de sécurité et de partage | Org-wide defaults, nouvelle intégration qui touche plusieurs clouds | Comité de revue avant tout environnement : une autorité de conception, un responsable sécurité, un responsable métier à l’autorité transverse. Trois personnes, pas douze. |
| Risque domaine | Un cloud ou une business unit, avec des effets possibles sur les voisins | Un Flow sur un objet partagé, un prompt template utilisé par plusieurs équipes, une modification de contrat d’API | Responsable de domaine, plus un plan de retour arrière écrit |
| Changement isolé | Aucune dépendance entre systèmes | Un champ sur un objet non partagé, un rapport, un tableau de bord, un permission set dans un seul groupe | Un approbateur, revue légère |
Le niveau lui-même doit être gouverné. La façon la plus simple d’échapper à un processus lourd est de déclarer son propre changement isolé. La réponse : une analyse d’impact obligatoire, avec des questions simples. Le changement touche-t-il un objet partagé ? Modifie-t-il un contrat d’API ? Change-t-il qui peut voir ou modifier quels enregistrements ? Change-t-il ce qu’un agent peut faire ? Les réponses fixent le niveau. La préférence du demandeur, non.
Une gouvernance de release par environnements et contrôles
Un comité qui revoit chaque déploiement chaque semaine sera contourné par la première équipe sous pression de livraison. Une gouvernance qui tient est inscrite dans les environnements.
Le principe : une sandbox complète qui reflète la production, et un chemin de déploiement où des contrôles automatisés s’exécutent à l’entrée. Les changements qui passent les contrôles et restent sous le seuil de risque partent au rythme normal. Ceux qui lèvent une alerte vont à une personne. La revue humaine devient l’exception.
Ces contrôles relèvent de la pratique courante : analyse statique sur l’Apex, une limite de complexité des Flows au-delà de laquelle une revue de conception est exigée, contrôle des versions d’API, et un seuil de couverture de tests que l’équipe fixe et fait respecter. Le sponsor n’a rien à configurer. Il doit savoir quels contrôles tournent, ce qui déclenche une revue humaine, et qui a le droit de passer outre un contrôle en échec.
La cadence de release est elle aussi une décision de gouvernance. Une fenêtre de release fixe, précédée d’un court gel, rend la plateforme prévisible et laisse une piste d’audit : chaque changement d’une release est documenté, testé et attribuable à quelqu’un.
Les changements IA passent par la même porte
Agentforce ajoute des surfaces de changement qui ressemblent à des paramètres et se comportent comme de la logique métier. Le périmètre de l’agent (ses topics) décide de ce qu’on peut lui demander. Ses actions décident de ce qu’il peut faire : mettre à jour une Opportunity, envoyer un e-mail, appeler un système externe. Ses instructions décident de son comportement. Les prompt templates de Prompt Builder façonnent ce qu’il écrit. Une modification d’instruction non documentée équivaut à une règle non documentée dans un Flow.
Ils suivent donc le même contrôle des changements. Avant le début du build, le périmètre de l’agent est écrit. Avant la production, l’agent est testé contre des critères de réussite et d’échec définis à l’avance. Toute action qui modifie des données financières ou envoie un message externe garde un humain dans la boucle. Les prompt templates sont revus au même rythme de release que le reste, et une action qui écrit des enregistrements n’est jamais classée comme isolée. La note sur la gouvernance de Prompt Builder va plus loin sur les templates.
La gouvernance reste chez le client
Un intégrateur peut construire. Il ne doit pas détenir les droits de décision. Quand les droits d’administration, l’approbation des changements et la gestion des releases restent chez l’intégrateur après la mise en production, chaque petit changement devient un devis et une négociation de planning, et personne en interne ne sait pourquoi l’org est configurée ainsi.
Trois choses restent en interne : le modèle de permissions (qui peut voir et modifier quoi), la règle d’approbation des changements, et la gestion des releases. Les gros chantiers et le travail d’expert ponctuel peuvent aller à un partenaire, à deux conditions. L’intention de conception est écrite dans les standards du client, et les droits d’administration reviennent à la fin du projet. Aucune clause de contrat ne remplace un responsable interne qui peut dire non.
À vérifier
- Pouvez-vous nommer la personne qui décide au niveau plateforme, domaine et changement, et le délai d’une escalade ?
- Qui fixe le niveau d’un changement : le demandeur, ou une analyse d’impact ?
- Quels contrôles tournent avant la release, et qui peut passer outre un contrôle en échec ?
- Le périmètre, les actions, les instructions et les prompt templates des agents sont-ils dans le même journal des changements que les Flows ?
- Après la mise en production, qui détient les droits d’administration et la gestion des releases : votre équipe ou l’intégrateur ?