Pas encore de mission freelance à documenter publiquement — plutôt que d'inventer des témoignages ou des clients, voici des cas construits à partir de problèmes réellement rencontrés en poste (côté intégrateur et en équipe interne), reformulés avec des données et des contextes fictifs.
01
Exemple type · données fictivesServices B2B · ~40 salariés
Deux automatisations qui se marchent dessus sur le même objet Opportunité
Symptôme observé
Les commerciaux reçoivent parfois deux emails de confirmation identiques quand une opportunité passe à "Fermé/Gagné", et certains champs de suivi se réinitialisent sans raison apparente.
Diagnostic technique
Un Process Builder créé lors du déploiement initial et un Flow ajouté deux ans plus tard agissaient tous les deux sur le changement de statut de l'objet Opportunité, sans qu'aucun des deux intervenants n'ait connaissance de l'existence de l'autre. Les deux déclenchaient l'envoi d'un email et la mise à jour d'un même champ personnalisé, dans un ordre non garanti.
Solution mise en place
Cartographie de toutes les automatisations actives sur l'objet Opportunité, consolidation de la logique dans un unique Flow avec un ordre d'exécution explicite, désactivation propre (et non suppression immédiate) de l'ancien Process Builder après une période d'observation en sandbox.
Avant : Process Builder "PB_Opp_ClosedWon" + Flow "Opp_After_Save" → 2 déclencheurs concurrents.
Après : 1 Flow "Opp_ClosedWon_Consolidated" → ordre d'exécution documenté, email envoyé une seule fois.
Résultat
Fin des emails dupliqués et des réinitialisations de champs. Temps de diagnostic pour la prochaine automatisation sur cet objet réduit, grâce à la documentation laissée dans le Flow.
02
Exemple type · données fictivesDistribution / logistique · ~80 salariés
La synchronisation entre Salesforce et l'ERP ne remonte plus certaines commandes
Symptôme observé
Depuis plusieurs semaines, une partie des commandes validées dans Salesforce n'apparaissent pas dans l'ERP. L'équipe a pris l'habitude de vérifier manuellement chaque commande à risque avant de la considérer comme traitée.
Diagnostic technique
L'intégration reposait sur un middleware tiers déclenché par un champ de statut. Une mise à jour antérieure des règles de validation sur l'objet Commande empêchait certains enregistrements de passer par le statut attendu par le middleware, sans qu'aucune erreur visible ne soit levée côté Salesforce.
Solution mise en place
Traçage du flux de données de bout en bout (règles de validation → champ de statut → déclenchement du middleware → réception côté ERP), identification du sous-ensemble de commandes bloquées, correction de la règle de validation en conflit, et ajout d'une alerte visible en cas de nouvel échec de synchronisation.
Résultat
Reprise de la synchronisation automatique à 100 % sur les nouvelles commandes, et mise en place d'un indicateur simple permettant à l'équipe de repérer un futur incident sans attendre qu'un client s'en plaigne.
03
Exemple type · données fictivesAgence immobilière · ~25 salariés
L'assignation des leads se faisait encore à la main, avec plusieurs heures de retard
Symptôme observé
Chaque nouveau lead entrant via le formulaire du site web arrivait dans une file commune. Une personne de l'équipe l'attribuait manuellement au bon commercial selon le secteur géographique, parfois plusieurs heures après la réception — un délai critique sur ce type de leads.
Diagnostic technique
Aucune automatisation n'existait sur la création de Lead. Les critères d'attribution (zone géographique, budget, type de bien) étaient connus mais jamais formalisés ailleurs que dans la tête de la personne qui faisait la répartition.
Solution mise en place
Formalisation des règles d'attribution avec l'équipe, puis construction d'un Flow déclenché à la création du Lead : lecture des critères, attribution automatique au bon commercial via une table de correspondance, notification immédiate (email + tâche) au commercial concerné.
Flow "Lead_AutoAssign" : Get Records (table de correspondance zone → commercial) → Update Lead (Owner) → Send Email Alert + Create Task.
Résultat
Délai d'attribution ramené de plusieurs heures à quelques secondes. L'équipe a pu supprimer la tâche manuelle de répartition de son organisation quotidienne.
04
Exemple type · données fictivesIndustrie légère · ~60 salariés
Un rapport d'activité commerciale généré à la main chaque semaine
Symptôme observé
Chaque lundi, une personne de l'équipe commerciale passait environ une heure à exporter des données Salesforce vers Excel, les mettre en forme, et les envoyer par email aux trois managers concernés.
Diagnostic technique
Le rapport combinait des données déjà disponibles dans Salesforce (opportunités créées, closes, pipeline par commercial) mais aucun Report/Dashboard natif n'était structuré pour correspondre exactement au format attendu par les managers, d'où le recours à l'export manuel.
Solution mise en place
Construction d'un Report Salesforce natif reproduisant exactement le format attendu, puis automatisation de l'envoi hebdomadaire par email aux trois managers via un Flow planifié (Scheduled Flow), sans intervention humaine.
Résultat
Une heure par semaine récupérée pour l'équipe commerciale, et un rapport livré systématiquement le lundi matin à la même heure, sans dépendre de la disponibilité d'une personne en particulier.
Les cas présentés ci-dessus sont des exemples illustratifs de problèmes types rencontrés dans les environnements Salesforce des PME. Les secteurs, tailles d'entreprise et détails sont fictifs. Ils ne correspondent à aucune mission client identifiable.
Une situation qui ressemble à la vôtre ?
Décrivez votre problème lors d'un appel de cadrage gratuit de 30 minutes. Je vous dis honnêtement si ça correspond à ce que je peux traiter.