Le vocabulaire est arrivé du commerce en ligne : découpler la présentation de la logique métier, exposer le tout en API, recomposer librement. Appliqué au CRM, le mot d'ordre devient « composable » — assembler le meilleur de chaque brique plutôt que subir une suite intégrée. Sur le papier c'est séduisant. Sur les projets, la réalité mérite d'être regardée de près.
Ce que « headless » veut dire pour un CRM
Dans le commerce, le headless a un sens précis : le back-office gère catalogue, panier et commandes, et n'impose aucune vitrine. On branche dessus un site, une application, une borne.
Pour un CRM, la « tête » n'est pas une vitrine publique : c'est l'écran de travail d'un commercial ou d'un conseiller. Le découplage ne sert donc pas à changer de design, il sert à trois choses concrètes :
Faire vivre la donnée client hors du CRM. Un espace client, une application mobile terrain, un portail partenaire consomment les mêmes données sans que l'utilisateur mette jamais les pieds dans l'interface CRM.
Intégrer le CRM dans l'outil de travail réel. Le conseiller ne quitte pas son poste de travail métier : les objets CRM y sont exposés par API. C'est souvent là que se joue l'adoption, bien plus que dans l'ergonomie du CRM lui-même.
Remplacer une brique sans tout casser. L'argument le plus vendu, et le moins vérifié dans les faits.
Ce qui se découple bien, et ce qui résiste
Se découple bien : la consultation — fiches, historiques, catalogues — et les parcours transactionnels simples, où une API bien conçue rend service immédiatement.
Résiste beaucoup plus : tout ce qui porte de la logique métier implicite. Les règles d'attribution, les validations, les automatismes, les droits d'accès ligne à ligne. Ces règles vivent dans la plateforme, et les exposer proprement en API demande de les expliciter — ce que personne n'a jamais fait. C'est là que les projets dérapent : le chantier annoncé comme technique devient un chantier de clarification métier.
Résiste aussi : la cohérence transactionnelle. Une suite intégrée garantit qu'une opération touchant cinq objets aboutit ou échoue en bloc. En architecture composée, cette garantie n'existe plus par défaut. Il faut la reconstruire — idempotence, réconciliation, reprise sur erreur — et ce travail est systématiquement sous-estimé au chiffrage.
Le côté Salesforce : ce qui existe réellement
La plateforme est mieux outillée qu'on ne le croit pour ce type d'architecture. Les API REST et GraphQL exposent le modèle de données, la couche d'intégration permet d'exposer des services métier composés plutôt que des objets bruts, et le Data Cloud répond à un besoin différent mais complémentaire : réconcilier des données client venues de plusieurs systèmes.
Deux pièges reviennent systématiquement. Le premier : exposer les objets tels quels. On obtient une API qui reflète le modèle interne, avec ses champs techniques et son historique de compromis. Le jour où le modèle bouge, tous les consommateurs cassent. Une API doit exposer un contrat métier stable, pas un schéma de base.
Le second : oublier les quotas. Une plateforme comme Salesforce applique des limites de gouvernance — appels API, temps d'exécution, volumétrie. Une architecture composée multiplie mécaniquement les appels. Un projet qui n'a pas modélisé sa consommation d'appels découvre le problème en production, au pire moment.
Quand ça vaut le coup, et quand c'est une mode
Ça vaut le coup quand il existe plusieurs consommateurs réels de la donnée client — un espace client, une application terrain, un partenaire — ou quand une brique doit pouvoir être remplacée pour une raison identifiée : fin de contrat, contrainte réglementaire, rachat.
C'est une mode quand l'argument est « ça nous rendra agiles ». Une architecture composée n'est pas plus agile par nature : elle déplace la complexité de l'intérieur de la plateforme vers les interfaces entre les briques. Si votre équipe ne sait pas gouverner des contrats d'API, versionner, tester des intégrations, la complexité déplacée devient une complexité subie.
Les compétences que ça déplace
Sur un projet composable, le profil rare n'est ni le développeur d'interface ni l'expert de la plateforme. C'est l'architecte d'intégration : quelqu'un capable de dessiner des contrats d'API stables, de trancher ce qui reste dans la plateforme et ce qui en sort, et de tenir ces décisions dans la durée.
Viennent ensuite deux profils qui montent : le consultant qui sait expliciter des règles métier — traduire « on a toujours fait comme ça » en spécification testable — et le profil données capable de modéliser une vue client unifiée. Notre article sur les compétences Salesforce qui tirent le marché détaille les passerelles depuis un profil existant.
Les missions ouvertes reflètent ce déplacement : les intitulés « architecte d'intégration » et « architecte Data Cloud » ont pris la place des postes de paramétrage pur.