À propos · positionnement & méthode
Cette page sert à donner du contexte : qui intervient quand vous me confiez un environnement Salesforce, comment je travaille, ce que je vois sur le terrain, et pourquoi j'ai choisi ce format précis d'intervention plutôt qu'un autre.
Si vous hésitez entre une ESN, un intégrateur, un freelance en régie, une équipe interne, la section FAQ plus bas est probablement le meilleur endroit où commencer.
Parcours · 04 chapitres
Pas d'effet rétrospectif. Chaque étape éclaire le format actuel d'intervention.
J'ai commencé en développement back-end avant de basculer sur Salesforce un peu par hasard, sur un projet de migration. C'est en y travaillant que j'ai compris ce qu'on pouvait réellement faire avec la plateforme, bien au-delà du CRM commercial classique. Je m'y suis spécialisé.
J'ai passé plusieurs années en mission via des cabinets de conseil et des intégrateurs. J'y ai appris à travailler en équipe sur des projets structurés, à cadrer un besoin avec un client, à livrer dans un format contractuel. J'y ai aussi vu les limites du format : un consultant junior livré sur des sujets complexes, des phases de cadrage qui s'éternisent, des handovers qui se passent mal.
J'ai ensuite rejoint une équipe interne, du côté du client cette fois, dans l'industrie. Pas pour déployer Salesforce, mais pour maintenir et faire évoluer une org industrielle de grande taille : plus de 1 000 classes Apex, 300 flows actifs, des intégrations SAP et un CPQ complexe (Conga/Apttus). C'est là que j'ai vraiment vu ce qui se passe après un déploiement : la dette technique qui s'accumule, les automatisations oubliées, les besoins non couverts, les outils contournés.
Aujourd'hui, je propose ce savoir-faire en indépendant, avec un positionnement volontairement étroit : optimisation et dépannage d'environnements Salesforce déjà en production, pour des PME sans équipe technique interne. Missions courtes, périmètre fixe, prix affichés. C'est le format qui correspond à ce que je sais faire le mieux.
Vision du métier
Ce qui suit n'a rien de très original. C'est ce qui devrait être évident, mais qui mérite quand même d'être posé clairement.
La plupart des problèmes que je résous ne sont pas des problèmes techniques. Ce sont des problèmes de lecture : personne n'a pris le temps de regarder ce qui existait avant d'ajouter une couche supplémentaire.
Avant de modifier quoi que ce soit dans un environnement, je passe du temps à lire l'existant. Les flows, les intégrations, les Validation Rules, l'historique. La majorité des incidents que je vois ont été causés par des modifications faites sans cette lecture préalable.
Une mission réussie n'est pas une mission où ça marche le jour de la livraison. C'est une mission qui tient six mois plus tard, sans que vous ayez besoin de me rappeler. Ça implique de tester sérieusement, de documenter ce qui est livré, et de ne pas livrer ce qui n'est pas prêt.
Si votre besoin n'est pas pour moi, je le dis. Si je vois un problème plus large que celui qu'on m'a confié, je le signale, sans essayer d'élargir la mission à tout prix. Si je découvre un blocage technique, je préviens dans la journée plutôt que de le découvrir avec vous à la livraison.
FAQ · questions/réponses
Format conversationnel : l'objectif est d'expliquer, pas de vendre.
Pourquoi ce format précis d'intervention, et pour qui il a du sens.
Ce n'est pas une question de mieux ou de moins bien, c'est une question de format.
Une ESN est faite pour porter de gros projets ; sur un environnement déjà en place qui dysfonctionne, une équipe de plusieurs personnes est disproportionnée : en coût, en temps, en coordination. Avec moi, un seul interlocuteur, pas de transfert de dossier, pas de réunion à six.
Parce que c'est ce que je vois le plus sur le terrain.
Beaucoup d'entreprises ont déployé Salesforce il y a plusieurs années, puis enchaîné prestataires et admins sans jamais consolider. L'ensemble tient debout mais n'exploite qu'une fraction de ce dont il est capable. Le déploiement neuf n'est pas mon créneau. C'est le moment d'après qui m'intéresse, là où beaucoup de valeur se crée rapidement.
Sur un gros projet, le travail technique ne représente qu'une partie du temps ; le reste, c'est coordination et reporting, nécessaire pour piloter de grosses équipes, mais ce n'est pas mon métier.
Je suis bon sur des missions courtes, trois à dix jours, périmètre clair. Au-delà, un consultant seul devient un facteur de risque. Quand un besoin sort de mon créneau, je l'oriente plutôt que de tirer une mission de force.
Les PME ont rarement besoin d'une grande transformation ; elles ont besoin que ce qui existe fonctionne et que les irritants quotidiens soient réglés.
Passer par une grosse structure pour un besoin de quelques jours donne un parcours disproportionné : cadrage de plusieurs semaines, proposition volumineuse, plusieurs interlocuteurs, pour un problème réglable en trois jours sans intermédiaire. Un interlocuteur direct, un périmètre court et un prix clair sont plus adaptés.
Comment se passe une mission, concrètement.
Je commence toujours par regarder ce qui existe avant de toucher à quoi que ce soit : lire les flows, comprendre les intégrations, identifier les dépendances. C'est l'étape qu'on saute par manque de temps, et celle qui évite la majorité des problèmes.
Je travaille en sandbox quand c'est possible, jamais en production sans validation explicite, et je documente au fil de l'eau. Ce qui est livré doit être reproductible sans moi.
Parce que c'est plus juste pour les deux parties.
Pour vous : vous savez exactement ce que vous achetez, ce que vous payez, et quand. Pour moi : ça force à cadrer en amont : si le périmètre est flou, je ne m'engage pas sur délai et prix. Le TJM en régie pousse souvent à étirer ; un format cadré aligne les intérêts.
Salesforce est un outil 100 % dans le navigateur : l'essentiel de mon travail se passe dans Setup et les sandbox. Pas de présence physique nécessaire.
Quand un consultant se déplace pour trois jours, vous payez son temps de transport, souvent facturé, sans valeur ajoutée. À distance, je suis aussi plus flexible : intervenir sur trois jours espacés ou faire un point d'une heure, sans contrainte logistique.
Préférence pour l'asynchrone, par mail. Réponse sous 48 heures ouvrées en moyenne.
Les visios, je les réserve aux phases qui le justifient : cadrage initial, restitution finale, points techniques en temps réel. Pas de rituels imposés. Vous ne devriez pas bloquer deux heures de visio par semaine pour qu'une mission de trois jours se déroule bien.
Ce que je vois dans la grande majorité des environnements que je reprends.
Les mêmes problèmes reviennent dans la majorité des environnements que je reprends.
Des automatisations en conflit (Workflow Rule, Process Builder, Flow récents sur le même objet, sans coordination), des intégrations cassées qu'on vérifie à la main, des champs plus utilisés mais toujours là, des profils mal paramétrés, une documentation absente ou datée de plusieurs années.
Salesforce est puissant et permet à beaucoup de monde de construire dessus. C'est ce qui en fait un outil utile sur la durée.
Mais sur plusieurs années, ça produit une sédimentation : couche sur couche, sans consolidation ni relecture d'ensemble. Ce n'est pas anormal. C'est ce qui arrive à tout système qui vit. À un moment, ça vaut la peine de prendre du recul : état des lieux, nettoyage, documentation, refactor. C'est ce que je propose.
L'appel de cadrage dure 30 minutes. C'est gratuit, sans engagement, et le seul objectif est de vérifier que ce que je propose correspond réellement à ce que vous cherchez. Si ce n'est pas le cas, je le dis.