Service

Intégration CRM et ERP
au Québec

Si quelqu'un recopie chaque semaine une donnée d'un logiciel vers un autre, ce n'est pas un poste, c'est une intégration qui manque.

Intégrer un CRM et un ERP consiste à faire circuler automatiquement les clients, les commandes et les statuts entre les deux, au lieu de les recopier à la main. Le travail réel n'est pas technique : il consiste à décider quel système fait foi pour chaque champ, et à rendre visible chaque échec de transfert.

Le problème que ça règle

Une entreprise finit rarement avec un seul logiciel. Elle a un CRM pour les ventes, un ERP ou un système comptable pour les commandes et la facturation, une boutique en ligne, un outil de courriel, parfois un logiciel de terrain. Chacun a été choisi séparément et fait bien son travail. Aucun ne parle aux autres.

Le pont entre eux, c'est un humain. Quelqu'un ouvre le CRM, lit une commande gagnée, ouvre l'ERP, la ressaisit. Quelqu'un exporte un fichier le vendredi et l'importe ailleurs le lundi. Ce travail ne figure sur aucune fiche de poste, il n'apparaît dans aucun budget, et il consomme des heures chaque semaine. Il produit surtout des écarts : deux systèmes qui donnent deux chiffres différents pour la même question, sans que personne sache lequel croire.

Les erreurs de recopiage sont les plus chères de toutes parce qu'elles se découvrent tard. Un prix mal reporté sort en facture. Une adresse mal saisie part au transporteur. Un statut oublié laisse un client sans nouvelle. Chacune de ces erreurs coûte plus que l'intégration qui l'aurait évitée, et elles reviennent tant que le pont reste humain.

Ce que ce n'est pas

Un mandat mal orienté coûte plus cher à tout le monde qu'un mandat refusé au premier appel. Voici donc ce que je ne vends pas, et ce que je dis quand la demande ne colle pas avec ce que je sais faire.

  • Ce n'est pas le remplacement de vos logiciels. Si votre CRM et votre ERP font correctement leur travail, ils restent. L'intégration ajoute le pont entre eux, elle ne relance pas un projet de migration dont personne n'a envie.
  • Ce n'est pas un connecteur acheté et branché. Quand un connecteur existant couvre votre cas, je vous le dis et vous l'installez sans moi. Je construis quand la logique métier ne rentre pas dans une case de configuration, ce qui est le cas dès qu'il y a des règles de correspondance, des exceptions ou des données à nettoyer au passage.
  • Ce n'est pas une agence. Il n'y a pas de chargé de projet entre vous et le code. La personne qui comprend vos règles de correspondance est celle qui les programme.
  • Ce n'est pas un service de garde. Je livre une surveillance qui alerte quand une synchronisation échoue, et je corrige ce que j'ai construit. Je ne vends pas d'astreinte de nuit.
  • Ce n'est pas un forfait chiffré sur une idée. Tant que les champs, les règles de correspondance et le sens de la synchronisation ne sont pas écrits, un prix ferme n'est qu'un pari.

Ce que vous recevez

Le livrable n'est ni une maquette ni un rapport. C'est un logiciel qui tourne, avec ce qu'il faut autour pour qu'il continue de tourner le jour où je ne suis plus au dossier.

  • Une synchronisation entre vos systèmes, planifiée ou déclenchée par événement
  • Une table de correspondance des champs, écrite et validée avec vous
  • Les règles de résolution quand deux systèmes ne sont pas d'accord
  • Un journal consultable de ce qui a été transféré, quand, et avec quel résultat
  • Des alertes quand une synchronisation échoue, avant que quelqu'un s'en aperçoive
  • La reprise des données existantes et le nettoyage des doublons au passage
  • Le dépôt de code à votre nom, avec la documentation pour reprendre sans moi

L'outillage reste le même d'un projet à l'autre. Une pile réduite se maintient et se transmet ; une pile choisie pour être à la mode se paie deux ans plus tard, quand plus personne ne veut y toucher.

  • Django
  • Celery
  • Redis
  • PostgreSQL
  • TypeScript

Comment ça se passe

Toujours dans cet ordre, et vous voyez sortir quelque chose de chaque étape. Personne ne disparaît trois mois pour revenir avec une surprise.

  1. Cartographier ce qui circule à la main

    On liste les allers-retours réels entre vos outils : qui recopie quoi, dans quel sens, à quelle fréquence, et ce qui se passe quand la personne est absente. Cette carte donne l'ordre de priorité, parce qu'elle chiffre le temps perdu au lieu de le supposer.

  2. Décider qui a raison

    Deux systèmes finissent toujours par se contredire sur une adresse, un prix ou un statut. Avant d'écrire une ligne, on tranche pour chaque champ lequel des deux fait foi et ce qui arrive au perdant. Cette décision appartient à l'entreprise et pas au code, et l'ignorer produit des synchronisations qui écrasent des données valides.

  3. Construire le pont, dans un seul sens d'abord

    Une synchronisation à sens unique se vérifie facilement et se corrige sans dégât. On la met en service, on la regarde tourner, puis on ouvre le second sens seulement si le métier l'exige. Beaucoup de projets s'arrêtent au premier sens et s'en portent bien.

  4. Rendre les échecs visibles

    Une intégration silencieuse est dangereuse : elle donne l'impression que tout va bien jusqu'au jour où l'on découvre trois semaines de données manquantes. Chaque transfert laisse une trace consultable, et un échec déclenche une alerte le jour même.

  5. Surveiller, corriger, documenter

    Les premières semaines révèlent les cas particuliers que la cartographie n'avait pas vus, et je les traite. Ensuite, la documentation explique comment ajouter un champ, changer une règle et relancer un transfert, pour que vous ne dépendiez pas de moi pour une modification mineure.

Ce que ça change une fois en ligne

Une intégration rate presque toujours pour la même raison, et cette raison n'est pas technique. Elle rate parce que personne n'a tranché qui a raison. Le CRM et l'ERP contiennent tous les deux une adresse de facturation, un nom d'entreprise et un prix. Ils divergent dès la première semaine. Si le code n'a pas de réponse écrite, il en invente une, et il finit par écraser une donnée que quelqu'un venait de corriger.

Cette décision appartient à l'entreprise, champ par champ, et elle prend plus de temps que le développement. Pour l'adresse, c'est souvent l'ERP qui fait foi parce que c'est lui qui expédie. Pour le statut d'une occasion de vente, c'est le CRM. Pour le prix, la réponse dépend de qui a le droit d'accorder un rabais. Un tableau avec trois colonnes, le champ, le système maître et ce qui arrive au perdant, vaut mieux qu'un cahier des charges de trente pages.

Le deuxième piège est le sens de la synchronisation. Un pont bidirectionnel paraît plus complet, il est surtout deux fois plus difficile à vérifier et il crée des boucles quand une modification déclenche une modification en retour. Commencer à sens unique permet de regarder le pont tourner pendant quelques semaines et de le corriger sans dégât. Beaucoup de projets s'arrêtent là et s'en portent très bien.

Le troisième piège est le silence. Une intégration qui échoue sans rien dire est pire que pas d'intégration du tout, parce que l'équipe cesse de vérifier. Chaque transfert doit laisser une trace lisible par un humain, et chaque échec doit produire une alerte le jour même. Cette partie représente une part réelle du travail et elle est presque toujours coupée en premier pour tenir un budget. C'est le mauvais endroit où couper.

Reste la question des outils d'automatisation sans code. Ils font très bien leur travail sur les enchaînements simples entre deux services connus, et quand ils suffisent je le dis. Ils deviennent coûteux dès qu'apparaissent des règles de correspondance, des exceptions métier, du volume ou des données à nettoyer au passage. Le signe qu'il faut écrire le pont plutôt que de le configurer, c'est le moment où le scénario visuel devient impossible à relire.

Enfin, une interface de programmation change, et il faut construire en le sachant. La logique métier vit d'un côté, la couche qui parle au fournisseur de l'autre. Quand le fournisseur modifie son format, la réparation touche une seule zone du code. La surveillance vous prévient dès le premier transfert raté, et le dépôt étant à votre nom, un autre développeur peut intervenir si je ne suis pas là.

Ce que j'ai construit

Des applications en ligne, que vous pouvez ouvrir et juger vous-même. J'ai écrit le code de chacune, du premier écran à la mise en production.

Le reste est sur la page des réalisations.

J'écris aussi sur la façon dont ces applications sont faites :

Questions fréquentes

Combien coûte une intégration entre un CRM et un ERP ?
Le prix dépend du nombre d'objets à synchroniser et de la propreté des données de départ, pas du nom des logiciels. Un pont qui pousse les commandes gagnées d'un système vers l'autre est un projet court. Une synchronisation bidirectionnelle de clients, de produits, de prix et de stocks demande beaucoup plus, surtout si les deux bases contiennent déjà des doublons. Je chiffre après avoir vu les données réelles.
Faut-il changer de CRM ou d'ERP ?
Presque jamais. Si vos outils font correctement leur travail, les remplacer coûte plus cher que de les relier, et impose à vos équipes un changement d'habitudes dont elles n'ont pas besoin. Le cas où la question se pose vraiment, c'est un logiciel sans interface de programmation utilisable : là, le pont devient fragile, et le remplacement mérite d'être étudié.
Que se passe-t-il quand les deux systèmes ne sont pas d'accord ?
C'est la question centrale et elle se tranche avant le code, champ par champ. Pour chaque donnée, un système fait foi et l'autre suit. Quand aucun ne peut faire foi, la synchronisation s'arrête sur le cas et le signale au lieu de choisir toute seule. Une intégration qui décide en silence finit par écraser des données valides.
Comment savoir qu'une synchronisation a échoué ?
Par une alerte le jour même, pas par un client mécontent trois semaines plus tard. Chaque transfert laisse une trace consultable qui dit ce qui est passé, ce qui a été ignoré et pourquoi. C'est la partie qu'on oublie le plus souvent dans une intégration, et c'est celle qui fait la différence entre un pont fiable et une bombe à retardement.
Utilisez-vous des outils comme Zapier ou Make ?
Quand ils suffisent, oui, et je vous le dis. Ces outils règlent très bien les enchaînements simples entre deux services connus. Ils deviennent coûteux et difficiles à déboguer dès qu'il y a des règles de correspondance, des exceptions métier, du volume ou des données à nettoyer au passage. C'est à ce moment qu'écrire le pont revient moins cher que de le configurer.
Et si un des logiciels change son interface de programmation ?
Cela arrive, et le code est écrit pour que ce soit une réparation et pas une reconstruction : la logique métier est séparée de la couche qui parle au fournisseur. La surveillance détecte la panne dès le premier transfert raté. Le dépôt étant à votre nom avec sa documentation, un autre développeur peut faire la réparation si je ne suis pas disponible.

Voir aussi : Intégration de systèmes, Logiciel de gestion sur mesure, Automatisation et agents IA. Tous mes services.

Parlons de ce que vous voulez construire

Le premier appel sert à savoir si le sur-mesure est la bonne réponse à votre problème. Si ce n'en est pas une, je le dis, et vous aurez perdu une demi-heure plutôt qu'un budget.

tokamdarius@gmail.com