Salesforce
Maintenir Salesforce sans équipe interne : le cas d'une coopérative laitière et de son portail adhérents
par Paul Mantez, Co-fondateur & Développeur
Une org Salesforce en production ne reste pas en l'état. Les versions se succèdent trois fois par an, les demandes métier s'empilent, un flow ajouté pour un cas particulier finit par en bloquer un autre, et un jour l'intégration avec l'ERP s'arrête parce que le mode d'authentification a été retiré. Quand l'entreprise n'a pas d'administrateur Salesforce à plein temps, ce qui est le cas de la plupart des PME et des coopératives, la plateforme se dégrade doucement, jusqu'à ce que quelqu'un le remarque.
La réponse s'appelle la tierce maintenance applicative, et elle mérite mieux qu'un contrat d'heures. Cet article décrit comment on la pratique chez Ingredia et sa coopérative Prospérité Fermière, groupe laitier du Nord, avec un cas qui concentre les difficultés : deux orgs distinctes, et un portail où les éleveurs adhérents suivent chaque jour leurs apports de lait, leurs contrats et leurs factures.
Deux orgs, trois publics : d'abord savoir où on est
La première org porte l'activité commerciale : devis multi-devises, opportunités, service client, pilotage. La seconde fait vivre la coopérative : le portail des éleveurs, une boutique B2B d'intrants agricoles, les outils des techniciens de collecte. Près de 400 objets, plus de 90 flows, des packages métier tiers, et des tableaux de bord CRM Analytics que les adhérents consultent.
Les deux modèles de données ne se recoupent pas. Un « compte » n'est pas la même chose dans l'une et dans l'autre. Le premier réflexe, à chaque ticket, est donc de le rattacher à la bonne org avant de le qualifier. Ça paraît trivial ; c'est ce qui évite d'aller chercher un flow au mauvais endroit pendant une heure.
D'où le cadre qu'on a posé : un projet de tickets par org, avec des modules alignés sur les métiers de chacune (portail adhérent, e-commerce B2B, collecte et contrats, apports et facturation d'un côté ; ventes, devis, service de l'autre). Et à côté, un registre des décisions d'architecture et des apprentissages : pourquoi tel objet existe, pourquoi tel flow a été fait ainsi, ce qu'on a découvert en le touchant. C'est ce registre qui fait qu'une TMA survit au changement de personne, chez nous comme chez le client.
La règle qui ne se discute pas : la sandbox, avec le portail en tête
Chaque évolution est validée en sandbox avant la production. Ce n'est pas propre à ce client, c'est propre à Salesforce. Ce qui est propre au cas, c'est le point systématique sur l'impact côté portail.
Un portail Experience Cloud expose des composants, des tableaux de bord et des droits à des utilisateurs qui ne sont pas des employés. Un champ renommé, un composant remplacé, une permission modifiée : l'administrateur ne le verra pas depuis son profil, l'éleveur le verra dès sa prochaine connexion. On teste donc avec un profil d'utilisateur externe, pas avec un profil administrateur, et on déploie en dehors des moments où les adhérents consultent.
Sur le portail, la demande la plus parlante a été un filtre « hors lait écrémé » sur les livraisons mensuelles. Le widget natif ne se déployait pas correctement dans ce contexte ; plutôt que de forcer, on a livré un composant LWC dédié, testé en sandbox avec un compte éleveur, puis mis en production. Ce que voit l'adhérent est la seule mesure qui compte.
CRM Analytics : là où les alertes s'accumulent en silence
Les tableaux de bord CRM Analytics exposés aux éleveurs étaient fragiles : recettes en avertissement, datasets surdimensionnés, composants introuvables, doublons. Rien de tout ça ne bloque, et c'est le problème : personne ne regarde jusqu'à ce qu'un chiffre soit faux devant un adhérent.
On a mené un audit complet : chaque recette, chaque dataset, la sécurité par ligne (un éleveur ne doit voir que ses apports), la duplication des composants entre tableaux. Beaucoup d'alertes venaient de datasets qui avaient grossi au fil des ans sans être retaillés. On a corrigé d'abord ce qui est exposé aux utilisateurs, puis nettoyé le reste, en documentant dans le registre ce que chaque dataset alimente.
La leçon vaut pour toute org avec de l'analytique exposée : auditer avant d'ajouter. Chaque nouveau tableau de bord posé sur une base fragile hérite de sa fragilité.
Sur l'org commerciale : des développements ciblés, pas une refonte
La TMA n'est pas que du correctif. Sur l'org commerciale, deux exemples de ce que « faire évoluer » veut dire.
Les commerciaux négocient parfois à un taux de change spécifique, différent de celui de l'organisation. Un composant LWC sur les devis affiche les montants en euros calculés avec le taux négocié, pas le taux global : le commercial voit ce qu'il a réellement vendu, la direction aussi.
Autre cas : un compte prospect envoyé vers l'ERP pouvait être modifié pendant son transfert, avec des données incohérentes à l'arrivée. Un verrouillage du compte pendant l'envoi a réglé le sujet. Quelques lignes, un flow, un test en sandbox ; c'est le type de demande qui, sans TMA, attend six mois puis se règle par un contournement.
Sécuriser les intégrations avant que Salesforce ne coupe
L'intégration avec l'ERP passait par Talend, connecté à Salesforce en login et mot de passe sur l'API SOAP. Ça fonctionnait, et ça allait s'arrêter : Salesforce retire progressivement ces flux d'authentification.
La migration s'est faite vers OAuth 2.0 en flux JWT Bearer, via des External Client Apps, sur l'org de recette d'abord, puis en production, avec des certificats à durée de vie maîtrisée (et une date de renouvellement dans le registre). L'ancien flux est resté actif jusqu'à la bascule : zéro interruption des échanges avec l'ERP. C'est le déroulé qu'on applique à toute intégration héritée : le nouveau canal en parallèle, la bascule quand il est prouvé, l'ancien coupé ensuite.
Ce chantier-là, aucun utilisateur ne l'a vu. C'est exactement ce qu'on attend d'une maintenance.
Ce qu'une TMA doit vous garantir
Si vous cherchez un prestataire pour maintenir votre Salesforce, voici ce qui, selon nous, fait la différence entre une maintenance et un contrat d'heures.
| Ce qu'on attend | Ce que ça veut dire concrètement |
|---|---|
| Un cadre par org | Projet de tickets distinct, modules par métier, pas de fourre-tout |
| Une trace | Registre des décisions d'architecture et des apprentissages, lisible par le client |
| La sandbox systématique | Aucune évolution en production sans validation, avec test sous profil utilisateur externe s'il y a un portail |
| Un regard sur ce qui ne bloque pas | Audit des tableaux de bord, des flows en erreur silencieuse, des intégrations à échéance |
| Des évolutions, pas seulement des correctifs | Composants, flows, automatisations livrés dans le même cadre |
| Un rythme lisible | Forfait mensuel de jours, priorisation partagée, réactivité connue |
Le témoignage du client sur la page du cas parle de disponibilité et de réactivité. Ce sont les conséquences du cadre, pas des qualités en soi : quand tout est tracé et validé en sandbox, on peut être rapide sans être imprudent.
Questions fréquentes
Qu'est-ce qu'une TMA Salesforce et à quoi ça sert pour une PME ou une coopérative ?
La tierce maintenance applicative, c'est confier à un prestataire le maintien et l'évolution d'une org Salesforce en production : corriger ce qui casse, faire évoluer les flows et les composants, sécuriser les intégrations, répondre aux utilisateurs. Pour une structure sans administrateur Salesforce à plein temps, c'est ce qui évite que la plateforme se dégrade au fil des mises à jour et des demandes métier.
Comment faire évoluer un portail Experience Cloud sans perturber ses utilisateurs ?
En validant chaque évolution en sandbox avec un point systématique sur ce que verra le portail, avant tout passage en production. Les tableaux de bord, les composants et les droits exposés aux utilisateurs externes sont testés avec un profil de ce type, pas avec un profil administrateur. Et on garde une fenêtre de déploiement en dehors des moments où les adhérents consultent.
Combien coûte une maintenance Salesforce ?
Ça dépend du périmètre (nombre d'orgs, portails, intégrations) et du rythme des demandes. Le modèle le plus lisible est un forfait mensuel de jours, avec un projet de tickets partagé où tout est tracé et priorisé. Une TMA sérieuse commence à quelques jours par mois pour une org de PME ; c'est nettement moins qu'un administrateur salarié, et l'expertise couvre plus large.
Que faire des tableaux de bord CRM Analytics qui affichent des avertissements ?
Les auditer un par un : recettes en avertissement, datasets surdimensionnés, composants dupliqués ou introuvables, sécurité par ligne. Beaucoup d'alertes viennent de datasets qui ont grossi sans que personne ne les retaille. Après l'audit, on corrige ce qui est exposé aux utilisateurs en priorité, puis on nettoie le reste.
Comment sécuriser une intégration Salesforce en login et mot de passe ?
En la migrant vers OAuth 2.0 en flux JWT Bearer, via une External Client App, avec un certificat à durée de vie maîtrisée. On la déploie d'abord sur l'org de recette, puis en production, en gardant l'ancien flux actif jusqu'à la bascule : l'intégration ne s'interrompt jamais. C'est d'autant plus urgent que Salesforce retire progressivement les flux d'authentification par mot de passe.
Faut-il une TMA par org quand on a plusieurs orgs Salesforce ?
Un seul prestataire, mais un cadre par org : un projet de tickets distinct, des modules alignés sur les métiers de chaque org, et un premier réflexe à chaque ticket qui est de le rattacher à la bonne org. Deux orgs qui ne partagent pas leur modèle de données ne se maintiennent pas comme une seule.
Maintenir un Salesforce, ce n'est pas répondre aux tickets plus vite. C'est faire en sorte que, dans deux ans, l'org soit plus propre qu'aujourd'hui, que les intégrations n'aient jamais coupé, et que les éleveurs qui ouvrent leur portail chaque matin n'aient rien remarqué.
Votre org Salesforce vit sans administrateur dédié, avec un portail ou des intégrations à tenir ? On en prend la maintenance, cadre compris →