Faites-vous du code (Apex) ou de la configuration ?

Les deux. Je privilégie le déclaratif (Flows, configuration) quand il suffit, et je passe à l'Apex/LWC pour les besoins sur mesure ou les gros volumes.

Pouvez-vous intégrer Salesforce à mon site ou mes outils ?

Oui : connexion via API REST/Bulk, synchronisation de données, webhooks, web-to-lead, et passerelles avec votre facturation ou votre site Laravel/WordPress.

Travaillez-vous sur une org existante ?

Oui. Je commence par un audit (objets, automatisations, dette technique, tests) avant d'intervenir, pour ne rien casser dans une org déjà en production.

Gérez-vous les déploiements et les tests ?

Oui : tests Apex obligatoires, déploiements via Salesforce CLI ou change sets, recette en sandbox avant toute mise en production.

Expertise

Développeur Salesforce freelance

Développeur Salesforce : Apex, LWC et intégrations sur mesure

Salesforce, c'est puissant — et vite tentaculaire si personne ne tient la barre. Je développe l'Apex, les composants Lightning et les intégrations qui collent à votre façon de travailler, sans transformer votre CRM en usine à gaz.

Parlez-moi de votre projet Voir les services

Kylian Bellegarde, développeur Salesforce freelance en Martinique, travaillant sur du code Apex et une interface Lightning à l'écran.

Apex (classes, triggers, tests) et SOQL/SOSL maîtrisés.

Lightning Web Components (LWC) pour des interfaces sur mesure.

Automatisations (Flows) et intégrations via API REST/Bulk.

Je développe sur Salesforce depuis deux ans : Apex, Lightning Web Components, automatisations et intégrations. J'aide les entreprises à adapter leur CRM à leurs vrais process — pas l'inverse — avec un code testé et maintenable.

Salesforce sait faire énormément de choses sans une seule ligne de code. Objets personnalisés, champs, règles de validation, champs formule, Flows : avant de sortir l'Apex, je vais aussi loin que possible en déclaratif. C'est plus rapide à mettre en place, plus facile à reprendre par votre équipe, et ça survit mieux aux montées de version trois fois par an que Salesforce impose. Une automatisation construite en Flow reste visible et modifiable depuis l'interface ; une classe Apex, elle, suppose un développeur à chaque ajustement.

Mais le déclaratif a ses murs. Quand un trigger doit faire des calculs précis, quand un traitement touche des dizaines de milliers d'enregistrements, quand une logique doit s'exécuter dans un ordre garanti ou qu'il faut une interface que les composants standard ne couvrent pas, je passe au code. La règle que je m'applique est simple : du code seulement quand il apporte vraiment quelque chose qu'un Flow ne sait pas faire proprement. Trop d'orgs croulent sous des classes Apex qui auraient dû rester de la configuration — et qui deviennent une dette que plus personne n'ose toucher.

L'inverse existe aussi, et je le surveille autant : une org où tout est en Flow finit par empiler des dizaines d'automatisations qui se déclenchent sur le même objet, dans un ordre difficile à suivre, jusqu'à ce qu'une modification anodine en casse une autre à l'autre bout. Bien doser, c'est savoir regrouper, nommer clairement, et garder une trace de ce que fait chaque automatisation et pourquoi. Le but n'est pas de bannir le code ni de tout coder : c'est que chaque brique soit au bon endroit, lisible, et justifiée.

Concrètement, ça veut dire que je commence chaque mission par cadrer le métier — quels objets, quels process, quelles règles, qui voit quoi — avant de décider ce qui sera déclaratif et ce qui sera codé. Je pose le modèle de données proprement, parce qu'une relation mal pensée entre deux objets se paie cher des mois plus tard. Vous repartez avec une org où chaque automatisation a une raison d'exister, documentée, plutôt qu'un empilement opaque que votre équipe contourne au lieu de l'utiliser.

Côté code, je travaille en Apex — classes, triggers, batchs, méthodes asynchrones (futures, Queueable), jobs planifiés — et en Lightning Web Components pour les interfaces sur mesure. Les LWC me servent à construire des écrans qui vont au-delà du standard : un assistant de saisie guidé qui réduit les erreurs, un tableau de bord métier qui agrège ce que vos utilisateurs consultent vraiment, un composant embarqué dans une page Lightning, dans une Flow Screen ou dans un site Experience Cloud ouvert à vos clients ou partenaires. Je maîtrise aussi SOQL et SOSL pour interroger vos données efficacement, sans requête inutile.

Sur Salesforce, les tests Apex ne sont pas optionnels : la plateforme refuse tout déploiement en production sous 75 % de couverture. Je ne traite pas ce seuil comme une case à cocher qu'on remplit avec des tests vides. J'écris des tests qui vérifient le vrai comportement — les cas limites, les volumes, les permissions, les enregistrements qui ne respectent pas les conditions attendues — pour que vos automatisations ne lâchent pas le jour où un utilisateur fait quelque chose d'inattendu. Un test sérieux est aussi votre meilleure assurance lors des montées de version : si une release Salesforce change un comportement, c'est la suite de tests qui le révèle avant vos utilisateurs.

Je connais aussi les contraintes propres à la plateforme : les fameux governor limits qui plafonnent, par transaction, le nombre de requêtes SOQL, de lignes traitées, d'instructions DML ou de temps CPU. Coder sur Salesforce, c'est coder en pensant aux volumes dès le départ. Un trigger naïf qui marche sur dix enregistrements explose sur un import de mille ; je conçois en bulkifiant — une requête qui traite tout le lot plutôt qu'une requête par enregistrement dans une boucle — pour que ça tienne quels que soient les volumes que votre activité atteindra.

La sécurité fait partie du même réflexe. Sur Salesforce, qui voit quoi et qui peut modifier quoi se joue à travers les profils, les ensembles de permissions, les rôles et le partage : je respecte ces règles dans le code plutôt que de les contourner, pour qu'un commercial ne tombe jamais sur une donnée réservée à la direction. Quand je livre du LWC ou de l'Apex, je vérifie que les accès aux objets et aux champs sont contrôlés, et que les entrées utilisateur sont traitées proprement. Un CRM contient des données sensibles : il mérite qu'on code avec ce sérieux-là.

Un CRM qui vit en vase clos ne sert qu'à moitié. La vraie valeur arrive quand Salesforce parle à vos autres outils : votre site, votre facturation, votre support, votre ERP, votre plateforme d'e-mailing. J'intègre via les API REST et Bulk de Salesforce — la REST pour les échanges à l'unité et en temps réel, la Bulk pour les gros volumes en lot — et je mets en place des web-to-lead, des webhooks (Platform Events, appels sortants) et des synchronisations de données dans les deux sens, avec une gestion propre des échecs et des reprises pour qu'aucune information ne se perde en route.

C'est là que mon profil de développeur web complet fait la différence. Je ne fais pas que poser des appels d'API côté Salesforce : je code aussi l'autre bout. Une passerelle entre votre org et un back-office Laravel, un formulaire WordPress qui crée proprement un lead sans le doublonner, une synchro de catalogue ou de commandes depuis votre site marchand — je tiens les deux côtés du tuyau. Ça vous évite les allers-retours sans fin entre deux prestataires qui se renvoient la balle dès qu'une intégration coince, et ça raccourcit nettement le temps de mise au point.

Avant de connecter quoi que ce soit, je cadre les règles du jeu : quelle source fait autorité sur quelle donnée, comment on rapproche un enregistrement Salesforce d'un enregistrement de votre autre outil (par identifiant externe, par e-mail, par référence), et que faire en cas de conflit. C'est ce travail invisible qui sépare une intégration fiable d'une synchro qui crée des doublons et que tout le monde finit par débrancher. Je documente ces choix pour que vous sachiez, plus tard, exactement comment l'information circule entre vos systèmes.

Pour les déploiements, je travaille avec Salesforce CLI, le contrôle de version et des sandboxes : on recette dans un environnement isolé, copie de votre org, avant toute mise en production — jamais directement sur l'org qui fait tourner votre activité. Pour des structures plus légères, les change sets restent une option valable et je m'y adapte. Et si vous avez déjà une org existante, je commence par un audit — objets, automatisations, dette technique, état des tests, intégrations en place — pour intervenir sans rien casser de ce qui tourne déjà.

Je suis basé en Martinique et je travaille avec des clients dans les Antilles — Martinique, Guadeloupe, Guyane — comme en métropole. Salesforce étant une plateforme cloud, la distance ne change rien à la qualité du travail : sandbox partagée, accès délégué à votre org, échanges en visio et points réguliers suffisent à avancer ensemble. Le décalage horaire avec l'Hexagone reste raisonnable, et pour une entreprise antillaise, avoir un interlocuteur dans le même fuseau et la même culture de travail évite bien des malentendus et des réunions à des heures impossibles.

Concrètement, vous n'avez pas besoin de me confier les clés en grand : je travaille avec des accès délimités à ce dont la mission a besoin, et je vous restitue à chaque étape ce que j'ai modifié et pourquoi. Vous gardez la main sur votre org, et vous n'héritez jamais d'une boîte noire que vous seriez incapable de faire évoluer sans moi. Pour les besoins ponctuels, j'interviens aussi à la tâche — un trigger à corriger, un composant à ajouter, une intégration à fiabiliser — sans vous imposer un gros chantier dont vous n'avez pas l'usage.

Salesforce reste un univers d'experts, souvent porté par de grosses ESN aux tarifs et aux délais qui vont avec. Mon créneau, c'est l'inverse : un seul interlocuteur qui code, qui explique ses choix dans un langage clair et qui vous rend une org documentée. Pour les PME, les associations et les structures qui n'ont pas d'équipe Salesforce en interne, c'est souvent le bon format — assez d'expertise technique pour faire du solide, assez de proximité pour que vous compreniez ce que vous payez et ce que vous obtenez.

Je suis transparent sur une chose : je développe sur Salesforce depuis deux ans, je ne me présente pas comme un architecte aux dix ans de certification. Sur l'Apex, les LWC, les Flows, le modèle de données et les intégrations, je suis solide et je livre du concret. Pour un déploiement multi-cloud d'envergure (Marketing Cloud, CPQ, secteur réglementé avec gouvernance lourde) ou une refonte d'org à l'échelle d'un grand compte, je vous le dirai franchement et je vous orienterai vers la bonne ressource, plutôt que de prendre un chantier hors de ma zone. C'est aussi ça, travailler honnêtement : connaître ses limites et vous faire gagner du temps.

Apex + LWCCode testé sur mesure

75 %Couverture de tests minimale exigée

2 ansDe développement Salesforce

API REST/BulkIntégrations à votre écosystème

Les avantages

Un seul interlocuteur qui code Salesforce ET le reste de votre système web — pas de ping-pong entre prestataires sur les intégrations.
Déclaratif d'abord, Apex ensuite : une org plus légère, plus facile à reprendre et qui encaisse mieux les trois mises à jour annuelles de Salesforce.
Du code Apex réellement testé, au-delà du seuil de 75 % imposé : vos automatisations tiennent face aux cas limites et aux volumes.
Conception bulkifiée et pensée pour les governor limits dès le départ — ce qui marche sur dix enregistrements continue de marcher sur des milliers.
Permissions et partage respectés dans le code : chaque utilisateur ne voit que les données auxquelles il a droit.
Audit avant toute intervention sur une org existante : on cartographie la dette et les automatisations avant de toucher quoi que ce soit en production.

Les limites à connaître

Salesforce a un coût de licences réel, par utilisateur et par mois : pour une petite structure au budget serré, l'addition peut dépasser le besoin face à un CRM plus léger ou une solution sur mesure.
La plateforme impose ses governor limits (requêtes SOQL, lignes traitées, instructions DML, temps CPU par transaction) : tout ne se code pas comme on veut, il faut composer avec ces plafonds.
Salesforce impose trois mises à jour majeures par an : il faut anticiper d'éventuels ajustements et tester ses personnalisations à chaque release, c'est un entretien continu.
Mon expérience est de deux ans : pour une architecture multi-cloud d'envergure ou une org de grand compte avec une gouvernance lourde, un cabinet spécialisé sera plus adapté, et je le dis.

Salesforce est une plateforme formidable, mais ce n'est pas toujours le bon outil. Voici comment je raisonne quand on en discute pour votre projet.

Choisissez Salesforce si…

Vous êtes déjà sur Salesforce et vous voulez l'adapter à vos process plutôt que de plier votre activité à l'outil standard.
Vous avez des process commerciaux ou métier complexes qui justifient un vrai CRM structuré, avec rôles, permissions et automatisations.
Vous manipulez de gros volumes de données et d'enregistrements qui demandent une plateforme qui tient la charge.
Vous avez besoin que votre CRM se connecte proprement à un écosystème d'outils existants via des API robustes.
Votre équipe ou votre secteur impose déjà Salesforce comme standard et vous voulez quelqu'un qui code dessus correctement.

Préférez autre chose si…

Votre besoin se résume à suivre quelques contacts et des relances simples : un CRM léger, voire un outil no-code, vous coûtera bien moins cher.
Vous démarrez une activité avec un budget serré : les licences Salesforce pèsent vite, autant commencer plus simple et migrer plus tard si ça grossit.
Vous voulez surtout un outil métier sur mesure très spécifique : un développement Laravel dédié peut être plus pertinent et sans coût de licence par utilisateur.
Vous n'avez personne en interne pour faire vivre l'org au quotidien et vous ne prévoyez pas d'accompagnement : une solution clé en main demandera moins d'entretien.
Votre volume de données et vos process restent modestes : la puissance de Salesforce serait surdimensionnée pour ce que vous en feriez.