Profil hybride
Là où Salesforce et l'infrastructure ne font qu'une seule tête
Je ne suis pas une développeuse Salesforce qui connaît les serveurs, ni une administratrice système qui connaît Salesforce. Je résous des problématiques transverses qu'un spécialiste seul — d'un côté ou de l'autre — traiterait plus lentement, moins bien, ou pas du tout : les décisions des deux couches sont prises en même temps, par la même personne, avant que l'aller-retour habituel entre équipes ne commence. Les preuves citées ci-dessous sont des projets de formation et des projets personnels ; chaque page indique sa nature et sa période.
Trois cas où la combinaison change le résultat
- 01
Reprise de données Heroku ↔ Salesforce, avec une app mobile terrain
Le problème — Un assureur rachète un concurrent : les données du CRM racheté doivent remonter dans Salesforce (sens unique), et les assureurs de terrain ont besoin d'une application mobile qui lit et écrit dans la même org.
Un profil spécialiste seul
Un profil Salesforce s'arrête à la couche Apex REST et sous-traite l'infrastructure Heroku — les décisions d'intégration sont prises sans connaître les contraintes de l'autre côté. Un profil infra déploie l'app Heroku, mais ne conçoit ni le trigger Apex d'External ID ni la Matching Rule qui bloquent les doublons à la source.
Ce que je livre
Les deux : les endpoints Apex REST, l'application Node.js/PostgreSQL qui les consomme, Heroku Connect configuré objet par objet, deux environnements isolés reliés par une pipeline, jusqu'au runbook de déploiement. L'environnement de staging existait avant que la première ligne d'Apex ne soit écrite — pas après.
Où ça compte — Assurance et finance : réconcilier deux portefeuilles clients où un doublon n'est pas une gêne mais un dossier orphelin et un risque de non-conformité.
- 02
Discipline DevOps appliquée aux releases Salesforce
Le problème — Livrer des changements Salesforce à répétition sans casser la production, avec une traçabilité auditable de chaque mise en prod.
Un profil spécialiste seul
Un profil Salesforce sait coder la fonctionnalité, mais déploie en Change Set manuel, sans procédure de rollback documentée. Un profil DevOps sait construire un pipeline, mais ne connaît pas les pièges du déploiement de métadonnées Salesforce — pas d'annulation native, ordre de dépendance entre composants.
Ce que je livre
Une discipline DevOps réelle — validation automatisée de chaque Pull Request contre l'org, authentification serveur à serveur JWT Bearer, clé privée supprimée du runner après chaque exécution, procédure de rollback SFDX documentée — appliquée à la façon dont les releases Salesforce sont livrées, pas seulement à la façon dont elles sont codées.
Où ça compte — Tout secteur régulé — santé, énergie, finance : chaque changement en production doit être traçable et réversible, pas seulement fonctionnel.
- 03
Contrôle d'accès d'une intégration, conçu côté Salesforce
Le problème — Une intégration Salesforce expose des endpoints REST : quel utilisateur les appelle, avec quels droits, et à quelles données peut-il accéder ?
Un profil spécialiste seul
Un développeur Salesforce livre l'endpoint en s'appuyant sur un profil existant trop permissif. Une équipe infra configure l'authentification côté serveur — mais ne sait pas quel Permission Set, quelle vérification CRUD/FLS ou quelle Sharing Rule limite réellement l'accès côté Salesforce.
Ce que je livre
Je conçois les droits de l'intégration côté Salesforce — utilisateur d'intégration dédié, Permission Set explicite, vérifications CRUD/FLS, WITH SECURITY_ENFORCED — en même temps que l'authentification côté serveur, dans le même sprint. Les accès sont cadrés avant la mise en production, pas trois tickets plus tard.
Où ça compte — Santé et luxe : les intégrations qui font transiter de la donnée patient ou de la provenance produit — là où un accès mal cadré n'est pas un détail technique mais une atteinte à la confiance.
Ce que la combinaison élimine
- L'aller-retour entre l'équipe Salesforce et l'équipe infra/DevOps sur chaque décision d'intégration.
- Les décisions prises d'un côté sans connaître les contraintes de l'autre — un trigger conçu sans savoir comment l'infra le sollicite, un pipeline conçu sans connaître les limites de déploiement Salesforce.
- Le délai entre « l'API est auditée » et « le contrôle est en place » : les deux se font dans le même sprint.
Un poste transverse à pourvoir ?
Si le poste touche à la fois Salesforce et l'infrastructure — intégration, migration, mise en production tracée, automatisation des déploiements — c'est exactement le terrain où mon profil fait gagner du temps à une équipe.