À 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. Pas pour déployer Salesforce, mais pour maintenir et faire évoluer un environnement déjà en production depuis plusieurs années. 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.
Je travaille en indépendant depuis quelques années, avec un positionnement volontairement étroit : optimisation et dépannage d'environnements Salesforce déjà en production, pour des PME qui n'ont pas d'équipe technique en 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 moins bien — c'est une question de format.
Une ESN est construite pour porter de gros projets, avec plusieurs consultants, des chefs de projet, des architectes, des phases de cadrage longues. Ça correspond à un certain type de besoin : déploiement initial, refonte structurelle, projets multi-équipes sur plusieurs mois. Sur ces sujets-là, c'est souvent le bon format.
Quand on me contacte, le besoin est généralement différent : un environnement existe déjà, il fonctionne plus ou moins, et quelque chose dysfonctionne ou n'a jamais été optimisé. Faire intervenir une équipe de plusieurs personnes pour ce type de mission, c'est souvent disproportionné — en coût, en temps, en coordination.
Avec moi, vous avez un seul interlocuteur. Pas de transfert de dossier en interne, pas de réunion à six personnes pour décider qui prend le sujet. Pour des interventions courtes et ciblées, c'est tout simplement plus efficace.
Parce que c'est ce que je vois le plus sur le terrain.
Beaucoup d'entreprises ont déployé Salesforce il y a deux, trois, cinq ans. Le déploiement initial s'est plus ou moins bien passé. Puis des évolutions ont été ajoutées au fil du temps — par un prestataire, puis un autre, puis un admin interne, puis personne. Aujourd'hui, l'environnement fonctionne, mais bien en dessous de ce qu'il devrait.
Le déploiement neuf n'est pas mon créneau. Il y a d'excellentes ESN et intégrateurs pour ça, qui font ce travail très bien. Ce qui m'intéresse, c'est le moment d'après : quand l'outil est en place et qu'il faut le faire fonctionner réellement. C'est moins glamour, mais c'est là que beaucoup de valeur peut être créée rapidement.
Sur un gros projet, le travail technique ne représente qu'une partie du temps. Le reste, c'est de la coordination, de la documentation interne, du reporting, des comités, des arbitrages. Ce n'est pas mauvais — c'est 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, livrable identifié. Au-delà, je deviens un facteur de risque pour vous : un consultant seul ne peut pas porter un projet de plusieurs mois sans risque de discontinuité — congé maladie, transfert de savoir, absence de relais.
Quand un besoin sort de mon créneau, je le dis. Et j'oriente vers un format ou un acteur plus adapté plutôt que d'essayer 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.
Une PME qui passe par une grosse structure pour un besoin de quelques jours se retrouve souvent avec un parcours qui ne lui correspond pas : un cadrage de plusieurs semaines, une proposition formelle volumineuse, un consultant junior sur la mission, plusieurs interlocuteurs. Pour un problème qui aurait pu être réglé en trois jours sans intermédiaire.
Je ne dis pas que ce n'est jamais pertinent — pour certains besoins, c'est la bonne approche. Mais pour beaucoup de demandes que je vois passer, un interlocuteur direct, un périmètre court et un prix clair sont plus adaptés. C'est ce que j'essaie de proposer.
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 a tendance à sauter par manque de temps — et c'est celle qui évite la majorité des problèmes par la suite.
Je travaille en sandbox quand c'est possible, et jamais directement en production sans validation explicite. Je teste chaque scénario avant de considérer qu'une automatisation est livrable.
Je documente au fil de l'eau, pas après coup. Ce qui est livré doit être reproductible et compréhensible, sans moi. C'est ce qui fait la différence entre un consultant qu'il faut rappeler tous les six mois et une intervention qui tient dans la durée.
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 vous le recevez. Pas de devis qui dérive en cours de route, pas de jours qui s'allongent.
Pour moi : ça force à cadrer correctement en amont. Si le périmètre est flou, je ne peux pas m'engager sur un délai et un prix. Donc je pose plus de questions, je creuse plus tôt, je suis plus rigoureux sur la phase de proposition.
Le TJM en régie, je l'ai fait pendant des années. Ça convient à certaines situations. Mais sur des missions courtes, ça pousse souvent à des comportements qui n'arrangent personne : étirer un peu, multiplier les points, facturer le confort plutôt que le résultat. 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, dans des sandbox, dans la console. Il n'y a pas de matériel à brancher, pas de serveur à toucher, pas de présence physique nécessaire.
Quand un consultant se déplace pour une mission de trois jours, vous payez deux choses : son travail, et son temps de transport (souvent facturé, parfois déguisé en demi-journée). Sur des missions courtes, ce surcoût peut représenter une part significative du budget pour aucune valeur ajoutée concrète.
À distance, je peux aussi être plus disponible et plus flexible. Je n'ai pas besoin de bloquer une semaine complète chez vous — je peux intervenir sur trois jours espacés, ou faire un point d'une heure si nécessaire, sans contrainte logistique.
Préférence pour l'asynchrone, par mail. Je réponds en journée sous 4 heures en moyenne — dans tous les cas sous 24 heures ouvrées.
Les visios, je les utilise pour les phases qui le justifient : cadrage initial, restitution finale, points techniques qui demandent du dialogue en temps réel. Je n'impose pas de rituels — pas de point hebdo systématique, pas de comité de pilotage si le sujet ne le mérite pas.
L'idée, c'est d'optimiser pour votre temps. Vous ne devriez pas avoir à 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 qui entrent en conflit : un Workflow Rule créé il y a plusieurs années, un Process Builder ajouté plus tard, un Flow construit récemment, qui agissent tous sur le même objet sans coordination. Personne ne sait dans quel ordre ils s'exécutent ni ce qu'ils font exactement.
Des intégrations qui ne fonctionnent plus correctement : la sync avec l'ERP, le connecteur CRM marketing, le lien avec l'outil de facturation. Quelque chose s'est cassé un jour, on a appris à vérifier manuellement, et le problème de fond n'a jamais été traité.
Des champs créés pour un besoin spécifique d'une équipe à un moment donné, qui ne sont plus utilisés mais qui restent là. Des profils mal paramétrés. Des Validation Rules qui empêchent des actions légitimes. Une documentation qui n'existe pas, ou qui date de plusieurs années.
Salesforce est extrêmement puissant et permet à beaucoup de monde de construire dessus : intégrateurs, admins, consultants externes, équipes internes, freelances ponctuels. Ce n'est pas un défaut — c'est ce qui en fait un outil utile sur la durée.
Mais sur plusieurs années, ça finit par produire une sédimentation : couche sur couche, sans consolidation, sans relecture de l'ensemble. Chaque intervenant construit en partant de ce qu'il voit, sans toujours comprendre pourquoi telle Validation Rule existe ou à quoi sert tel champ custom.
Il n'y a rien d'anormal là-dedans. C'est ce qui arrive à tout système qui vit et qui sert. Mais à un moment, ça vaut la peine de prendre du recul : faire un état des lieux, nettoyer ce qui ne sert plus, documenter ce qui reste, refactoriser ce qui peut l'être. C'est précisément le type d'intervention 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.