Intégrateur NetSuite : relier le CRM et la finance, du devis à l’encaissement

Le 14 mars, un commercial passe une affaire en « Gagnée » dans le CRM. Trois semaines plus tard, le contrôleur de gestion de la filiale britannique ne trouve ni commande ni facture dans NetSuite : le bon de commande signé est resté dans une pièce jointe d’e-mail, l’ADV attendait un numéro de compte client, et personne n’a prévenu le commercial que rien n’avait été facturé (exemple fictif). La vente existe deux fois, dans deux outils, et le chiffre d’affaires nulle part.

Ce scénario ne vient pas d’un mauvais paramétrage comptable. Il vient des passages entre le CRM et la finance, que personne n’a écrits avant le projet. C’est là que se décide la valeur d’un projet NetSuite, et c’est là qu’il faut juger un intégrateur NetSuite : sur ce qu’il propose de relier, de reprendre et de maintenir, pas seulement sur sa connaissance de l’outil.

Ce qu’un intégrateur NetSuite doit relier

Le périmètre d’un projet NetSuite

NetSuite, l’ERP en mode SaaS d’Oracle, couvre de série la comptabilité et la finance ; selon les modules souscrits, il gère aussi les achats, les stocks, la facturation et, avec l’édition OneWorld, la consolidation entre filiales. Il propose aussi ses propres fonctions CRM ; mais quand les commerciaux travaillent déjà dans Salesforce ou HubSpot, le projet ne les en fait pas sortir. Le projet NetSuite comprend donc, qu’on l’écrive ou non, tout ce qui vient du CRM : les clients, les devis, les commandes gagnées, et ce qui doit y retourner.

Si vous hésitez encore entre NetSuite, Odoo et SAP, notre comparatif pour DAF pose les critères. Cet article part du principe que le choix est fait.

Pourquoi la chaîne casse aux coutures, pas au cœur comptable

Le plan de comptes, les journaux, les règles de rapprochement : un intégrateur NetSuite sait les paramétrer, et l’outil les cadre. Ce qui n’est cadré par personne, c’est la frontière entre deux équipes. Le commerce considère qu’une affaire est terminée quand elle est signée ; la finance considère qu’elle commence quand la commande existe. Entre les deux, chaque information passe de main en main : par un connecteur, par une ressaisie, ou pas du tout.

La comptabilité, NetSuite la fait de série ; ce qui casse, ce sont les coutures avec le CRM.

Du devis à l’encaissement : les quatre coutures

Connecter Salesforce et NetSuite, ou HubSpot et NetSuite, revient à décider de quatre passages. Les principes généraux d’une intégration ERP et CRM s’appliquent ; voici ce qu’ils donnent sur la chaîne du devis à l’encaissement.

Le devis : dans le CRM ou dans NetSuite, mais pas dans les deux

NetSuite sait produire des devis, et le CRM aussi. Le risque n’est pas de choisir l’un ou l’autre, c’est de laisser les deux coexister : un devis révisé dans le CRM, un autre émis par l’ADV dans NetSuite, et un client qui reçoit deux versions. Décidez où naît le devis, qui peut le modifier après envoi, et à quel moment il devient une commande.

La commande gagnée : ce qui doit passer, et à quel moment

Le passage d’une opportunité en « Gagnée » est le déclencheur le plus naturel, et le plus piégeux. Une affaire peut être gagnée sans être facturable : bon de commande client manquant, conditions encore en discussion, client pas encore créé côté finance. Écrivez ce qui doit accompagner la commande (client, filiale de facturation, articles, quantités, conditions de paiement, contact de facturation) et ce qui se passe quand une information manque : la commande est bloquée, ou elle arrive incomplète et quelqu’un la complète.

Le catalogue et les prix : NetSuite fait foi, le CRM lit

Un article créé dans le CRM et absent de NetSuite produit une commande impossible à facturer. Une remise accordée dans le CRM et inconnue de la finance produit une facture contestée. La règle la plus simple à tenir : les articles et les grilles de prix sont maintenus dans NetSuite, et le CRM les lit. Les exceptions, comme une remise négociée, ont un circuit écrit.

L’encaissement : ce qui doit revenir au commercial

C’est la couture la plus souvent oubliée, parce qu’elle va dans l’autre sens. Le commercial qui relance un client pour un renouvellement doit savoir, depuis le CRM, qu’une facture est en retard de paiement. Choisissez les statuts qui remontent : facture émise, échéance, paiement reçu, encours. Inutile de tout remonter ; il faut que le commercial n’ait plus à écrire à la comptabilité pour savoir.

Plusieurs filiales, un seul client

Quelle filiale porte le client, et dans quelle devise

Dans l’édition OneWorld de NetSuite, chaque client est rattaché à une filiale principale, et peut être partagé avec d’autres filiales lorsque la fonction correspondante est activée. Dans le CRM, ce même client est un compte, qui ne porte pas forcément de filiale de facturation. Tant que cette correspondance n’est pas décidée, le connecteur fait un choix à votre place : il crée le client dans une filiale par défaut, ou il en crée un par filiale. Décidez quelle filiale facture quel compte, dans quelle devise, et ce qui se passe quand un même groupe client achète à deux de vos filiales.

L’identifiant qui relie le compte CRM au client NetSuite

Le nom de société ne suffit pas : « ACME Distribution », « ACME Distribution Ltd » et « Acme Distrib. » sont trois chaînes différentes pour un connecteur (exemple fictif). Il faut un identifiant stable, stocké des deux côtés : l’identifiant interne NetSuite reporté sur le compte CRM, ou un identifiant externe commun. Sans lui, chaque synchronisation est une recherche approximative, et chaque erreur de rapprochement crée un client de plus.

Dédoublonner avant de synchroniser

Un connecteur ne corrige pas une base : il la recopie. Si le CRM contient trois fiches pour le même client, NetSuite en recevra trois, et la consolidation par client sera fausse dès le premier mois. Le dédoublonnage se fait avant la première synchronisation, avec une règle écrite sur la fiche qui survit. Notre guide pour corriger les doublons entre CRM et ERP sans recréer détaille la méthode. C’est ce type de travail que turnK a mené chez Mirakl : suppression des doublons, correction des paramètres de synchronisation entre HubSpot et Salesforce, et règles de gouvernance pour la suite.

Trois façons de connecter le CRM à NetSuite

Le mode de connexion se choisit sur ce que vous devez synchroniser et sur qui le maintiendra, pas sur la démonstration.

Le connecteur prêt à l’emploi

Il synchronise les objets prévus par son éditeur, ni plus ni moins. Il se met en place sans développement, et c’est son éditeur qui le fait évoluer, tant que vos besoins restent dans son périmètre. Sa limite apparaît dès qu’un champ personnalisé ou une règle propre à votre entreprise n’entre pas dans ce qu’il sait faire.

La plateforme d’intégration

Une plateforme d’intégration fait transiter les données entre les deux outils selon des scénarios que l’on configure. Elle laisse plus de liberté sur les règles, les transformations et la gestion des erreurs. En contrepartie, quelqu’un doit tenir ces scénarios à jour quand un champ change dans le CRM ou dans NetSuite.

Le développement sur les API NetSuite

NetSuite expose des API, regroupées sous le nom SuiteTalk, et un langage de script, SuiteScript. Pour une nouvelle connexion, Oracle demande d’utiliser l’API REST : les intégrations en SOAP existantes fonctionnent encore, mais leur arrêt est programmé avec la version 2028.2 de NetSuite. Un développement sur mesure peut couvrir les cas les plus spécifiques. Il demande une documentation tenue et une équipe capable de le reprendre, sinon il devient une boîte noire.

Chez ACME Distribution (exemple fictif), le connecteur prêt à l’emploi couvrait les clients et les commandes, mais pas la filiale de facturation, saisie dans un champ personnalisé. Chaque commande arrivait dans la filiale par défaut et la comptabilité la déplaçait à la main. Le défaut ne venait pas de l’outil : la règle de rattachement n’avait jamais été écrite.

Choisir son intégrateur NetSuite sur vos données

Deux intégrateurs NetSuite qui maîtrisent l’outil peuvent conduire à deux projets très différents. La différence se voit dans ce qu’ils proposent de faire de vos données. Pour le rôle et le déroulé d’un projet ERP en général, lisez notre article sur le rôle d’un intégrateur ERP ; voici ce qui est propre à NetSuite et au CRM.

Qui porte la reprise

Clients, contacts de facturation, articles, encours, historique de factures : chaque lot doit avoir un responsable, une règle de nettoyage et une date de gel. Un devis qui écrit « reprise des données fournie par le client » vous laisse ce travail. Demandez qui extrait, qui nettoie, qui valide, et ce qui n’est pas repris.

Qui maintient la connexion après le démarrage

Le démarrage n’est pas la fin. Un champ ajouté dans le CRM, une nouvelle filiale, un nouveau taux de TVA : chaque changement peut casser un flux. Demandez qui surveille les erreurs de synchronisation, qui est prévenu quand une commande est rejetée, et comment vos équipes reprennent la main.

Les questions à poser avant de signer

Elles découlent de votre chaîne : là où le diagnostic en tête d’article a trouvé une couture rompue, demandez à l’intégrateur comment il la traite, avec quel mode de connexion, et qui la tient ensuite. Une réponse qui ne parle que de paramétrage laisse la couture à votre charge.

Le principe vaut au-delà de NetSuite. Orhatek, cabinet de conseil en solutions RH, gérait ses ventes et sa facturation entre Excel et Sellsy, avec des outils non connectés, des ressaisies, et une comptabilité Pennylane qui n’était pas synchronisée avec le CRM. turnK a migré les données de Sellsy vers HubSpot et relié HubSpot à Pennylane. Ce n’était pas un projet NetSuite, ni un projet ERP, mais c’était la même couture : le CRM et la finance qui doivent parler des mêmes clients et des mêmes chiffres. Lire le cas Orhatek.

« Deuxième fois que je fais appel à l’expertise de turnK et ravi du rendu. Équipe très efficace et professionnelle, soucieuse du résultat final. C’est un partenaire de choix dans notre développement. » — Julien Chevalier, CEO d’Orhatek

Par où commencer

Écrire la chaîne telle qu’elle est aujourd’hui

Avant le premier atelier, prenez une affaire signée le mois dernier et suivez-la jusqu’à l’encaissement. Notez chaque outil qu’elle traverse, chaque personne qui la touche, chaque information recopiée. Une seule affaire suffit à montrer quelles coutures sont rompues, et vous arrivez devant un intégrateur NetSuite avec une liste de décisions plutôt qu’une liste de fonctionnalités.

Ce que turnK apporte

turnK fiabilise les données qui circulent entre le CRM, NetSuite et vos autres outils : reprise et dédoublonnage des clients et des articles, correspondance entre comptes et filiales, connexions entre le CRM et la finance, règles écrites sur ce qui fait foi. L’objectif est simple à vérifier : le jour où une affaire est gagnée, la finance la voit, et le jour où elle est payée, le commercial le sait.