API et intégrations sur mesure : des logiciels qui communiquent, sans multiplier les ressaisies.
Une information saisie au bon endroit rejoint les bons logiciels, avec la trace de ce qui a été transmis, accepté ou refusé.
CRM, gestion commerciale, facturation, boutique en ligne, application mobile, prestataires : nous concevons, sécurisons et maintenons les échanges entre vos systèmes, selon ce que chacun permet.
Illustration en six étapes, données fictives. Trois logiciels indépendants : un CRM, qui fait foi pour le client et les conditions commerciales ; une gestion des commandes, qui fait foi pour la préparation et la date de livraison ; une facturation conservée, qui fait foi pour les factures et les échéances. 1. La commande CO‑2318 est acceptée par le client dans le CRM. 2. Le bordereau d'échange ECH‑7731 reprend six informations, avec la clé CO‑2318‑v1. 3. Quatre contrôles réussissent et les valeurs sont converties au format de la gestion. 4. Le bordereau est émis. 5. La gestion le reçoit, le contrôle et l'accepte. 6. La commande GC‑9904 est créée : l'échange est appliqué, et le CRM l'affiche. La facturation n'a rien reçu : elle récupérera les données à facturer quand l'expédition sera confirmée.
Trois logiciels, deux échanges, six étapes
Schéma illustratif, entreprise et données fictives ; les échanges possibles dépendent des accès qu'offre chaque logiciel.
Vos logiciels font chacun leur part : l'information suit, sans être ressaisie à chaque étape.
Un CRM, un logiciel de gestion, une boutique, un outil de facturation : chacun est bon dans son rôle. Le travail se perd entre eux, quand une information doit être recopiée, vérifiée ou retrouvée.
CRM → gestion ou ERP
- Ce qui circule
- la commande acceptée
- Ce que l'équipe y gagne
- La préparation démarre sans ressaisie, dans un CRM ou un ERP structuré pour vos équipes.
Boutique en ligne → logiciel de gestion
- Ce qui circule
- commandes, stock, clients
- Ce que l'équipe y gagne
- Un stock qui reflète les ventes de votre boutique en ligne.
Application mobile → back-office
- Ce qui circule
- interventions, photos, signatures
- Ce que l'équipe y gagne
- Le bureau voit ce qui est fait sur le terrain, grâce à une application mobile reliée à votre back-office.
Logiciel métier → facturation
- Ce qui circule
- prestations réalisées
- Ce que l'équipe y gagne
- Des factures établies à partir des bonnes quantités.
Plateforme → prestataire de paiement
- Ce qui circule
- demande de paiement, confirmation
- Ce que l'équipe y gagne
- Un statut de paiement fiable, même si l'outil qui manquait reste à concevoir sur mesure.
Outils internes → services externes
- Ce qui circule
- messages, signatures, transport
- Ce que l'équipe y gagne
- Moins de copier-coller entre les onglets.
Relier n'est pas tout synchroniser : on choisit ce qui circule, dans quel sens, et quel logiciel fait foi.
Deux liaisons réalisées : le module Magento 2 de la Société des Avis Garantis raccorde une boutique à sa plateforme d'avis clients ; chez Adapt Shoes, l'application, le module de configuration et la commande s'appuient sur le scan 3D des pieds.
Une API, un webhook, un fichier planifié : la méthode que vos logiciels acceptent réellement.
Chaque logiciel offre ses propres portes d'entrée. Le choix dépend de ce qu'il propose, du délai acceptable et du volume d'échanges.
API, souvent dite REST
- À quoi elle sert concrètement
- Un logiciel en interroge un autre ou lui envoie une donnée, à la demande.
- Limites à connaître
- Il faut qu'elle existe, soit documentée et accessible avec votre abonnement.
Webhook
- À quoi elle sert concrètement
- Un logiciel prévient l'autre dès qu'un événement se produit, comme un paiement reçu.
- Limites à connaître
- L'appel peut se perdre : il faut un accusé et une reprise.
Synchronisation planifiée
- À quoi elle sert concrètement
- Un échange à heure fixe, quand l'immédiat n'est pas utile, comme la mise à jour des catalogues des vendeurs d'une marketplace.
- Limites à connaître
- Un décalage assumé entre deux passages.
Échange de fichiers
- À quoi elle sert concrètement
- Un export et un import contrôlés, pour un logiciel sans API.
- Limites à connaître
- Le format est à surveiller ; pas d'immédiat.
Connecteur de l'éditeur
- À quoi elle sert concrètement
- Une liaison prête, proposée par le logiciel lui-même.
- Limites à connaître
- Son périmètre est fixé par l'éditeur.
Traitement asynchrone et file d'attente
- À quoi elle sert concrètement
- Absorber les pics et les indisponibilités, quand le volume le justifie.
- Limites à connaître
- Une brique de plus à superviser.
Tous les logiciels n'ont pas d'API documentée, et une API n'autorise pas tout. Nous vérifions ce que chacun permet avant de promettre un échange, et l'immédiat n'est proposé que si l'architecture le permet.
Ajouter une fonction d'IA dans l'un de ces logiciels relève d'un autre savoir-faire : l'intégration de l'IA aux logiciels métiers.
Une donnée, plusieurs destins : vous savez où en est chaque échange.
La même commande CO‑2318, envoyée du CRM vers la gestion des commandes. Choisissez une situation : ce qui part, ce qui arrive, ce que répond la gestion, et ce que cela change pour vos équipes.
Bordereau ECH‑7731 · CRM → gestion des commandesclé CO‑2318‑v1
- N° de commande
- Envoyée par le CRM : CO‑2318
- Reçue par la gestion : réf. externe CO‑2318
- Client
- Envoyée par le CRM : CL‑0457
- Reçue par la gestion : client CL‑0457 (connu)
- Article
- Envoyée par le CRM : Pack atelier standard × 3
- Reçue par la gestion : ART‑118 × 3
- Montant HT
- Envoyée par le CRM : 4 860,00 €
- Reçue par la gestion : 4860.00 EUR
- Lieu de livraison
- Envoyée par le CRM : Dépôt Nord
- Reçue par la gestion : site DN‑2
- Livraison souhaitée
- Envoyée par le CRM : 14/11/2026
- Reçue par la gestion : 2026-11-14
Réponse de la gestion des commandes
201 Commande créée : GC‑9904
La commande existe dans la gestion : l'opération est appliquée.
Appliqué · commande GC‑9904 créée
Envoi · CRM → gestion
- Émis09:42:05
- Reçuaccusé technique
- Acceptécontrôles passés
- AppliquéGC‑9904 créée
- Dans le CRM
- Transmise · acceptée par la gestion (GC‑9904)
- Commandes dans la gestion
- GC‑9904
- Conséquence métier
- La commande GC‑9904 est à préparer. Le CRM affiche « acceptée par la gestion », avec sa référence.
- Intervention humaine
- Aucune.
Journal d'échange
- 09:42:05ECH‑7731 émis · clé CO‑2318‑v1
- 09:42:06reçu par la gestion
- 09:42:06accepté : contrôles passés
- 09:42:07appliqué : GC‑9904 créée · CRM mis à jour
Les cinq situations : ce que répond la gestion, l'état de la transmission et la conséquence pour vos équipes.
| Situation | Réponse | Émis · reçu · accepté · appliqué | Conséquence métier | Intervention humaine |
|---|---|---|---|---|
| A. Transmission réussie | Envoi : 201 · Commande créée : GC‑9904 | Envoi : Émis · Reçu · Accepté · Appliqué | La commande GC‑9904 est à préparer. Le CRM affiche « acceptée par la gestion », avec sa référence. | Aucune. |
| B. Donnée manquante | Envoi : 422 · Refusée : lieu de livraison obligatoire | Envoi : Émis · Reçu · Refusé · Non appliqué | Aucune commande n'est créée. La CO‑2318 est marquée « à compléter » dans le CRM, avec le motif du refus. | Le commercial complète le lieu de livraison ; l'échange repart avec la même clé. |
| C. Service indisponible | Essai 1 : Aucune réponse : la gestion des commandes ne répond pas. | Essai 1 : Émis · Pas de réponse · Accepté · Appliqué | Rien n'est créé. Le CRM affiche « transmission en attente », pas « transmise ». Le bordereau n'est pas perdu : il attend en file. | Aucune tant que les essais suivent leur cours. |
| D. Doublon | Envoi : 201 · Commande créée : GC‑9904 ; Renvoi : 200 · Déjà traitée : GC‑9904 (clé CO‑2318‑v1) | Envoi : Émis · Reçu · Accepté · Appliqué ; Renvoi : Émis · Reçu · Déjà traité · Rien de nouveau | Une seule commande, GC‑9904. Le renvoi est reconnu grâce à la clé partagée par les deux logiciels. | Aucune. |
| E. Données contradictoires | Mise à jour : 200 · Reçue ; écart sur la date de livraison, en attente de décision | Mise à jour : Émis · Reçu · En attente · Non appliqué | Rien n'est modifié : le CRM garde le 14/11, la gestion le 18/11. L'échange reste en attente de décision. | Le commercial vérifie l'écart et valide la règle convenue. |
- Émis : le bordereau est parti. Rien ne dit qu'il est arrivé.
- Reçu : le destinataire l'a entre les mains. Il ne l'a pas encore jugé.
- Accepté : ses contrôles sont passés. La commande n'existe pas encore.
- Appliqué : la commande existe dans la gestion. L'opération métier est faite.
Logiciels, données et réponses fictifs ; aucun système réel connecté. Les codes de réponse sont donnés à titre d'exemple.
Ce qui fait la fiabilité d'un échange : chaque cas difficile a sa règle écrite.
Un échange qui fonctionne le premier jour ne suffit pas. Il doit rester juste quand une donnée manque, quand un service s'arrête ou quand deux logiciels ne sont plus d'accord.
Transformation
- Le problème
- Deux logiciels ne nomment pas les choses de la même façon.
- Ce que nous prévoyons
- Une table de correspondance, testée : « Pack atelier standard » devient ART‑118.
Validation
- Le problème
- Une donnée incomplète arrive à destination.
- Ce que nous prévoyons
- Des contrôles avant l'envoi, et un refus explicite du destinataire, avec son motif.
Identifiants uniques
- Le problème
- Retrouver la même commande des deux côtés.
- Ce que nous prévoyons
- Chaque objet garde sa référence d'origine, de bout en bout.
Doublons
- Le problème
- Un renvoi crée un second objet.
- Ce que nous prévoyons
- Une clé partagée : un même échange ne s'applique qu'une fois. On parle d'idempotence.
Reprises
- Le problème
- Un service ne répond pas.
- Ce que nous prévoyons
- De nouveaux essais selon un calendrier convenu, puis une alerte.
Écarts de données
- Le problème
- Deux logiciels affichent deux valeurs différentes.
- Ce que nous prévoyons
- Un propriétaire par donnée ; l'écart signalé et tranché, jamais effacé en silence.
Rythme
- Le problème
- Tout n'a pas besoin d'être immédiat.
- Ce que nous prévoyons
- Immédiat, à l'événement ou planifié, selon le délai acceptable pour chaque donnée.
Rapprochement
- Le problème
- Un écart passe inaperçu pendant des semaines.
- Ce que nous prévoyons
- Une comparaison régulière des deux côtés, dont les différences sont listées.
Des échanges sécurisés dès la conception : chaque logiciel n'accède qu'à ce qu'il lui faut.
La sécurité d'une intégration se décide en la construisant : qui se connecte, avec quels droits, et ce qui se passe quand un fournisseur change ses règles.
- Authentification des systèmes
- Chaque logiciel se présente avec son propre compte technique.
- Autorisations
- Lecture ou écriture, type de donnée par type de donnée.
- Gestion des secrets
- Clés et mots de passe techniques hors du code, renouvelables.
- Protection des communications
- Échanges chiffrés quand ils passent par un réseau public.
- Validation des données
- Le minimum utile, vérifié à l'entrée comme à la sortie.
- Limites d'appels
- Débit maximal et quotas des fournisseurs respectés, avec surveillance des seuils.
- Journalisation
- Qui a envoyé quoi, quand, avec quel résultat, sans donnée sensible en clair.
- Reprises
- Un nouvel essai ne doit ni perdre ni dupliquer une opération.
- Versions d'API
- Version figée, puis tests avant chaque migration annoncée par l'éditeur.
- Dépendances aux fournisseurs
- Une API tierce peut changer, ralentir ou s'arrêter : un mode dégradé est prévu.
Nous sécurisons les connexions que nous développons. L'audit d'une application ou d'une API existante est une prestation distincte de notre pôle cybersécurité : sécuriser vos API.
Aucune intégration n'est conforme par défaut, ni disponible en permanence : les exigences se vérifient avec vos responsables et, si besoin, un conseil juridique.
De la carte des échanges à leur suivi : une connexion entretenue, pas posée puis oubliée.
Une intégration se conçoit, se teste sur ses échecs autant que sur ses réussites, puis se maintient.
Cartographier
Les logiciels, les données, les sens d'échange et ce dont chacun fait foi.
Vérifier les accès réels
API, exports, quotas, licences et conditions de chaque éditeur.
Écrire les règles
Propriétaires, contrôles, erreurs, doublons, écarts et alertes.
Développer et tester
Avec des données réalistes, y compris les refus, les pannes et les renvois.
Mettre en service
Progressivement, avec un journal et des alertes dès le premier jour.
Maintenir
Suivre les versions d'API et les changements d'éditeur, dans le cadre de l'hébergement et de la maintenance convenus.
Questions fréquentes sur les API et intégrations
Éditeurs différents, logiciels sans API, méthodes d'échange, pannes, doublons et maintenance.
Peut-on connecter deux logiciels qui ne viennent pas du même éditeur ?
Oui, c'est le cas le plus courant. Ce qui compte n'est pas l'éditeur, mais ce que chaque logiciel permet : une API, des exports, un connecteur, des notifications. Nous le vérifions logiciel par logiciel, y compris ce que votre abonnement autorise, avant de proposer une liaison.
Que faire si l'un de nos logiciels n'a pas d'API ?
Nous vérifions d'abord ses possibilités d'export et d'import, les connecteurs proposés par l'éditeur et ce que votre contrat autorise. Une synchronisation indirecte, par fichiers planifiés et contrôlés, convient parfois. Si le logiciel ne permet pas un échange fiable et autorisé, nous le disons plutôt que de le contourner.
Quelle différence entre API, webhook et synchronisation ?
Une API répond quand on l'interroge. Un webhook prévient un autre logiciel dès qu'un événement se produit, par exemple un paiement reçu. Une synchronisation compare et met à jour des données à intervalles réguliers. Une intégration combine souvent les trois, selon le délai acceptable.
Que se passe-t-il si l'un des services est indisponible ?
L'échange n'est pas perdu : il est conservé et de nouveaux essais sont faits selon des règles convenues. Pendant ce temps, l'autre logiciel affiche « en attente », jamais « transmis ». Si le service ne revient pas, une alerte prévient la personne désignée.
Comment éviter les doublons et les écarts de données ?
Chaque échange porte une clé unique : renvoyé deux fois, il n'est appliqué qu'une fois, à condition que les deux logiciels la gèrent. Chaque donnée a un logiciel qui fait foi ; quand deux valeurs diffèrent, l'écart est signalé et tranché selon la règle convenue, au lieu d'un remplacement silencieux.
Qui assure la maintenance lorsque les API évoluent ?
Les éditeurs modifient leurs API, leurs quotas ou leurs conditions. Nous pouvons suivre ces évolutions, tester les échanges avant chaque changement et corriger les connexions, dans le cadre d'un contrat de maintenance dont le périmètre est défini avec vous.
Vos logiciels, reliés selon vos règles : des échanges que vous pouvez suivre.
Dossier de cadrage · échanges entre logiciels
La carte des connexions
exemple à cinq logiciels · à refaire avec les vôtres
| Gestion | commandeCRM → gestion · le CRM fait foi | |||
|---|---|---|---|---|
| Facturation | aucun échangepas de lien direct | à facturergestion → facturation · après expédition | ||
| Boutique | clientboutique → CRM · fiche créée ou reprise | commande webboutique → gestion · stock vérifié | à définirfacture visible en ligne ? | |
| Paiement | aucun échangepas de lien direct | paiement reçuprestataire → gestion · par notification | règlementprestataire → facturation · rapprochement | paiementboutique ↔ prestataire · le prestataire fait foi |
| CRM | Gestion | Facturation | Boutique |
- Gestion · CRMcommandeCRM → gestion · le CRM fait foi
- Facturation · CRMaucun échangepas de lien direct
- Facturation · Gestionà facturergestion → facturation · après expédition
- Boutique · CRMclientboutique → CRM · fiche créée ou reprise
- Boutique · Gestioncommande webboutique → gestion · stock vérifié
- Boutique · Facturationà définirfacture visible en ligne ?
- Paiement · CRMaucun échangepas de lien direct
- Paiement · Gestionpaiement reçuprestataire → gestion · par notification
- Paiement · Facturationrèglementprestataire → facturation · rapprochement
- Paiement · Boutiquepaiementboutique ↔ prestataire · le prestataire fait foi
Légende · neuf questions à documenter
- Quels logiciels doivent communiquer ?Ceux d'aujourd'hui, ceux qui restent, ceux qui arrivent.
- Quelles données circulent ?Le minimum utile, champ par champ, et leur format.
- Qui est propriétaire de chaque donnée ?Le logiciel qui fait foi quand deux valeurs diffèrent.
- Quels événements déclenchent les échanges ?Une validation, un paiement, une heure fixe.
- Quelles API ou méthodes sont disponibles ?API documentée, export, fichier, connecteur de l'éditeur.
- Quels contrôles et droits d'accès ?Comptes techniques, autorisations, données vérifiées.
- Comment traiter erreurs et doublons ?Refus, nouvel essai, clé unique, alerte.
- Comment vérifier et superviser les échanges ?Journal, tableau de suivi, seuils d'alerte.
- Qui maintient les connexions dans la durée ?Versions d'API, quotas, changements d'éditeur.
Une intégration fiable commence par la carte : quels logiciels, quelles données, qui fait foi, et ce qui se passe quand un échange échoue. Nous la dressons avec vous avant d'écrire la première connexion.
- Un inventaire des logiciels et de leurs accès réels
- Des règles écrites : propriétaire, contrôles, erreurs, doublons
- Un journal et un suivi des échanges après la mise en service
Réponse sous 24 à 48 heures ouvrées.
contact@crawleragency.com
+33 4 94 36 20 09
N'envoyez ni clé d'API, ni identifiant, ni export de données par le formulaire : ils s'échangent selon des modalités convenues ensemble.