Sommaire
Une intégration API entre CRM, comptabilité et boutique doit faire plus que déplacer des champs. Elle doit préserver le sens des données, éviter les actions répétées et permettre à une personne de résoudre les échanges qui échouent. Les coûts les plus difficiles à prévoir apparaissent souvent dans les exceptions, la reprise et la maintenance, plutôt que dans le premier appel réussi.
En bref
- Décidez quel système fait référence pour chaque donnée.
- Distinguez un échange reçu d’une opération réellement terminée.
- Prévoyez les doublons, les limites d’usage, les reprises et les alertes.
Commencer par un flux métier complet
Prenons une situation fictive : une commande arrive dans la boutique, crée une occasion dans le CRM et doit produire une facture dans la comptabilité. Une connexion qui crée seulement la fiche client n’achève pas ce parcours. Il faut définir ce qui confirme la commande, quand la facture peut être créée et comment les employés voient un échec.
Choisissez un premier flux limité, mais complet. Décrivez son déclencheur, les informations requises et son état final. Incluez une annulation ou une modification. Cet exercice évite de construire plusieurs connexions partielles dont personne ne possède le fonctionnement d’ensemble.
Le développement et l’intégration logicielle demandent une compréhension du processus actuel. Un connecteur du marché peut couvrir le besoin; un développement spécifique peut être nécessaire pour une règle particulière. Le bon choix dépend des comportements attendus, pas du nombre de logos disponibles dans un catalogue.
Nommer la référence pour chaque donnée
Le CRM peut faire référence pour le responsable commercial, la comptabilité pour les conditions de paiement et la boutique pour le contenu initial d’une commande. Documentez ces décisions. Si chaque système peut modifier la même valeur sans règle de priorité, une synchronisation peut tourner en boucle ou écraser une correction.
TableauNommer la référence pour chaque donnée · bloc partageable
| Décision à prendre | Risque sans règle | |
|---|---|---|
| Identité client | Identifiant partagé et table de correspondance | Plusieurs comptes pour une seule entreprise |
| Prix | Source, devise, taxes et date d’effet | Facture différente de la commande confirmée |
| État commande | Étapes permises et système responsable | Commande annulée encore traitée ailleurs |
| Conditions paiement | Source et droits de modification | Conditions remplacées par une valeur obsolète |
| Statut expédition | Provenance et fréquence d’actualisation | Client informé d’un état dépassé |
Les valeurs absentes demandent elles aussi une règle. « Aucun téléphone » et « champ non transmis » ne veulent pas toujours dire la même chose. Une mise à jour partielle ne doit pas nécessairement effacer un renseignement déjà présent. Faites examiner ces cas avant de choisir le format des échanges.
Prévenir les opérations répétées
Un service peut répondre lentement alors qu’il a déjà exécuté une opération. Si le système appelant recommence sans identifier la demande, il peut créer deux factures ou deux dossiers. Conservez un identifiant stable pour l’opération métier et définissez comment reconnaître un échange déjà traité.
Stripe documente un mécanisme de clés d’idempotence pour certaines requêtes de son API. Ce n’est pas une propriété universelle des API : les garanties, les durées et les opérations couvertes doivent être vérifiées pour chaque fournisseur. Votre architecture doit aussi considérer les actions qui suivent l’appel, comme une notification ou une écriture dans un autre outil.
Testez la répétition volontaire d’un même événement. Le résultat attendu est une opération unique ou un refus explicite, selon le contrat. Un succès obtenu une seule fois ne démontre pas cette propriété. Vérifiez également les événements qui arrivent dans le désordre et les modifications concurrentes.
Concevoir une reprise compréhensible
Classez les erreurs : indisponibilité temporaire, limite d’usage, donnée invalide, accès refusé ou règle métier non satisfaite. Une indisponibilité peut justifier une nouvelle tentative; une donnée incorrecte exige souvent une intervention. Répéter indéfiniment la même erreur augmente les coûts et masque la cause.
Préparez une file des échanges à examiner avec l’identifiant du dossier, l’étape atteinte, la cause et la prochaine action. Les employés n’ont pas besoin d’un journal technique complet pour savoir qu’une facture n’a pas été créée. Ils ont besoin de savoir si la commande peut continuer et qui doit agir.
Une réconciliation périodique complète les événements reçus en temps réel. Elle compare les états entre systèmes pour repérer les éléments manquants. Un événement perdu, une intervention manuelle ou une panne prolongée peuvent produire des écarts même lorsque le service principal est revenu à la normale.
Limiter les droits et les données échangées
Attribuez à chaque connexion uniquement les accès nécessaires. Une intégration qui lit les commandes n’a pas automatiquement besoin de supprimer les clients. Prévoyez le renouvellement des identifiants, leur stockage et le retrait des accès. Les journaux ne doivent pas exposer les secrets ni recopier inutilement des données personnelles.
OWASP décrit notamment les risques d’autorisation, de consommation excessive de ressources et de confiance accordée aux API tierces. Dans votre projet, traduisez ces risques en vérifications concrètes : limites des droits, contrôles des entrées, validation des réponses et traitement d’une dépendance compromise ou indisponible.
Rendre les coûts visibles dans la soumission
Le budget doit distinguer découverte, accès aux outils, correspondance des données, développement, essais, surveillance et maintenance. Vérifiez les abonnements nécessaires, les volumes autorisés et les coûts variables. Un connecteur peu coûteux peut nécessiter un plan logiciel plus élevé ou un travail important de nettoyage.
Demandez ce qui est prévu quand une API change. Qui surveille les annonces du fournisseur? Comment une version nouvelle est-elle testée? Qui corrige une règle de correspondance? La maintenance ne consiste pas seulement à garder un serveur allumé : les systèmes connectés continuent d’évoluer.
Pour un CRM ou ERP sur mesure, gardez les règles d’échange documentées et testables. L’intégration doit rester compréhensible par une autre équipe. Cette transmission réduit la dépendance à une personne qui connaît seule l’origine d’une correspondance ou d’une exception.
Un flux illustré : commande, CRM et facture
Prenons une commande fictive COM-1042 reçue dans une boutique. La boutique est la référence de la commande; le CRM détient la relation commerciale; la comptabilité détient le numéro et l’état de la facture. Le flux proposé ci-dessous est un exemple d’architecture, à adapter aux garanties réellement offertes par les outils.
TableauUn flux illustré : commande, CRM et facture · bloc partageable
| État enregistré | Reprise prévue | |
|---|---|---|
| Réception de COM-1042 | Événement reçu avec identifiant stable | Un événement répété retrouve la même opération |
| Association au client CRM | Identifiant du client et résultat de rapprochement | Un client ambigu reste en revue, sans facture créée |
| Création de facture | Référence externe COM-1042 et numéro comptable | Après délai dépassé, rechercher le résultat avant de recréer |
| Mise à jour du CRM | Lien vers la facture et état de l’échange | Reprendre cette étape seule si elle échoue |
| Réconciliation | Commande, facture et état CRM rapprochés | Signaler les divergences à un responsable nommé |
Supposons que la comptabilité crée FACT-884, mais que la connexion se coupe avant de renvoyer son numéro. Le connecteur ignore si l’opération a réussi. Relancer aveuglément la création peut produire une deuxième facture. Il doit retrouver le résultat via une référence stable, ou utiliser un mécanisme d’idempotence documenté par l’API. Si aucune de ces garanties n’existe, le cas passe en rapprochement manuel plutôt que d’être automatiquement recréé.
Stripe documente ce principe pour ses propres requêtes; cela ne prouve pas que votre logiciel comptable le propose. Il faut lire les garanties de l’interface concernée, leur durée et leurs limites. Conserver une clé dans le connecteur ne rend pas à lui seul une opération externe idempotente.
Quatre essais à joindre au devis
- Envoyer deux fois le même événement : retrouver une commande et une facture, avec une trace du doublon reçu.
- Couper la réponse après création : retrouver la facture existante, sans en créer une deuxième.
- Bloquer temporairement le CRM après facturation : reprendre sa mise à jour sans relancer la facture.
- Modifier ou annuler une commande : appliquer une règle métier approuvée; ne pas supprimer automatiquement une facture déjà émise.
Le journal utile porte l’identifiant de commande, l’étape, la date, l’identifiant externe et le motif d’échec. Il évite de recopier sans nécessité les données personnelles ou les secrets de connexion. Un bouton « réessayer » doit expliquer ce qu’il va relancer et qui peut l’utiliser. Le livrable à demander est donc un flux avec ses états et ses exceptions, accompagné de la preuve de ces essais.
Questions fréquentes
Une intégration doit-elle fonctionner en temps réel?+
Pas toujours. Une mise à jour périodique peut suffire pour un rapport, tandis qu’une réservation de stock demande un autre niveau de fraîcheur. Définissez le délai acceptable par processus et les conséquences d’un retard avant de choisir l’architecture.
Pourquoi payer du développement si un connecteur existe?+
Un connecteur peut être la bonne solution. Vérifiez toutefois les champs, les règles, les erreurs et les limites qu’il couvre. Le développement spécifique doit répondre à un besoin identifiable, plutôt qu’à une préférence technique.
Comment détecter une synchronisation incomplète?+
Suivez les états métier et les échanges en échec, puis comparez périodiquement les données entre les systèmes. Un indicateur de disponibilité du service ne prouve pas que toutes les commandes ou factures ont été traitées.
Peut-on promettre qu’il n’y aura jamais de doublon?+
Il faut préciser les garanties par opération et les limites des outils. Des identifiants stables, des mécanismes d’idempotence et des contrôles de réconciliation réduisent le risque. Les essais doivent inclure les répétitions, les délais et les échecs partiels.
Sources et méthode
Stripe — Idempotent requests · OWASP — API Security Top 10, édition 2023. Sources consultées le 1er octobre 2026; les grilles et exemples de décision sont une analyse éditoriale de Daillac.
Cadrer vos échanges avant de multiplier les connecteurs
Présentez-nous les systèmes à relier, les données à échanger et un exemple d’exception. Nous pourrons définir le sens des flux, les contrôles et une première intégration vérifiable.
D
Rédigé par
DaillacStratégie numérique et ingénierie logicielle — Saint-Jérôme · Grande région de Montréal
