Le DSI avait validé “un petit développement API” pour synchroniser le CRM et l’outil métier. Douze mois plus tard, le petit développement avait un propriétaire unique, aucune doc, deux incidents par trimestre, et personne n’osait le toucher pendant les congés d’été.
Développer sur l’API d’un CRM n’est pas interdit. C’est juste un choix de dette — utile ou toxique selon le moment.
Les trois niveaux, dans l’ordre
Avant d’écrire une ligne, regardez s’il existe un connecteur natif maintenu. Puis un iPaaS (intégration low-code) capable de couvrir le flux avec monitoring. Puis seulement un développement custom.
Cet ordre n’est pas idéologique. Il reflète le coût réel de possession : build, run, sécurité, reprise sur incident, montée de version du CRM, départ du développeur qui “savait”.
À retenirLe bon critère n’est pas “est-ce possible via API ?”. C’est “qui maintiendra ça dans 18 mois, à quel coût ?”.
Quand le natif suffit (plus souvent qu’on croit)
Beaucoup de besoins “custom” sont en réalité des besoins de paramétrage : mapping de champs, déclencheurs, règles d’assignment, webhooks simples déjà exposés par l’écosystème éditeur.
Si le connecteur couvre 80 % du flux critique et que le reste est gérable par une tâche humaine rare, le natif gagne. La poursuite des 20 % restants en code est le premier piège d’ego technique.
Quand l’iPaaS est le bon milieu
L’iPaaS brille pour des flux moyens : transformer des payloads, router selon des conditions, journaliser, réessayer, alerter. Il accélère sans enfermer immédiatement dans un repo opaque.
Il devient dangereux quand on y construit une usine de cent scénarios sans gouvernance, ou quand on contourne des limites métier au lieu de corriger le modèle de données.
ConseilTraitez vos scénarios iPaaS comme du code : nommage, environnements, revue, propriétaire, tests. Le low-code sans discipline devient du no-control.
Quand le custom API se justifie vraiment
Développez quand le flux est cœur de métier, différenciant, stable dans ses règles, et insuffisamment couvert par l’existant — avec un volume ou une criticité qui rend le manuel inacceptable.
Exemples typiques : synchronisation complexe avec un ERP propriétaire, calcul de pricing spécifique, orchestration multi-systèmes avec compensation transactionnelle, exigences de latence ou de conformité que l’iPaaS ne garantit pas.
Même là, bornez le scope. Une API “passe-plat” bien testée bat une plateforme interne qui recrée un CRM parallèle.
| Situation | Approche | Signal d’alerte |
|---|---|---|
| Sync standard ESP / support | Natif | “On custom pour être futurs-proof” |
| 5–20 flux moyens | iPaaS gouverné | Scénarios sans propriétaire |
| Cœur métier différenciant | Custom borné | Scope qui grossit chaque sprint |
| Besoin flou, process instable | Ne pas développer | “On verra les règles plus tard” |
Les coûts cachés du custom
Authentification, rotation des secrets, gestion des rate limits, pagination, webhooks vs polling, idempotence, deduplication, observabilité, reprise après incident, compatibilité avec les versions d’API éditeur, RGPD (logs, données personnelles dans les payloads).
Ce n’est pas du détail. C’est le travail. Si votre estimation ignore ces lignes, multipliez-la.
AttentionUne intégration sans idempotence crée des doublons “aléatoires” impossibles à expliquer en comité. Ce n’est pas un bug rare : c’est un design manquant.
Mini-cas : supprimer du code pour gagner en fiabilité
Une ETI avait trois micro-services maison vers le CRM. Deux ont été remplacés par des connecteurs devenus matures chez l’éditeur. Le troisième, vraiment spécifique, a été réécrit — plus petit, avec monitoring et runbook.
Résultat : moins d’incidents, onboarding plus simple pour l’équipe data, et un budget de run enfin prévisible. Le progrès n’était pas “plus de tech”. C’était moins de surface.
Sécurité et données personnelles dans les payloads
Dès qu’une API touche des fiches contacts, vous manipulez des données personnelles. Limitez les champs transportés au strict nécessaire. Chiffrez les secrets, tournez les tokens, journalisez les accès sans logger des contenus inutiles. Un connecteur “pratique” qui dump toute la fiche dans un middleware mal sécurisé est un incident en attente.
Posez aussi la question de la sous-traitance : qui héberge l’iPaaS, où, avec quel DPA. Le custom n’échappe pas à ce cadre ; il le rend parfois plus explicite — ce qui est plutôt une bonne nouvelle.
Méthode de décision en une réunion
Écrivez le flux en langage métier. Listez volume, criticité, fréquence de changement des règles. Inventoriez natif / iPaaS / custom avec TCO sur 24 mois. Exigez un propriétaire run avant le build. Refusez le développement si les règles métier bougent chaque semaine.
Un expert CRM utile ici n’est pas forcément un développeur star : c’est celui qui empêche le sur-ingénierie autant que le bricolage.
ChecklistBesoin métier clair, alternative native évaluée, TCO 24 mois, propriétaire run, observabilité prévue, stratégie de version d’API, plan de rollback.
FAQ rapide
L’API officielle est-elle “gratuite” ? L’appel peut l’être ; le run ne l’est jamais. Comptez aussi les quotas et le temps humain.
Faut-il attendre que le process soit parfait ? Il doit être stable. Parfait, non. Flou permanent, oui abstention.
Et les webhooks ? Excellents pour réagir vite — à condition de signer, vérifier, et gérer les retries sans doubles effets.
Que faire d’un legacy custom opaque ? Le documenter ou le remplacer par pans. Le “on ne touche plus” est une dette qui grossit seule.
Développer par nécessité, pas par réflexe
L’API CRM est un moyen. Le but, c’est un flux fiable, observable, et tenable par votre organisation réelle — pas par le développeur héroïque du moment.
Pour choisir un CRM dont l’écosystème réduit le besoin de custom, partez de notre comparatif CRM. Pour arbitrer natif / iPaaS / code sur votre cas, faites-vous accompagner avant d’ouvrir le ticket “petit dev”.