Vous avez un projet d’intégration API et vous voulez un accompagnement sur mesure, de la stratégie au run ? Découvrez notre offre d’intégration API sur mesure.
Au-delà du choix d’un protocole, d’un SDK ou d’un outil, le vrai sujet reste toujours le même: qualité du mapping, idempotence des traitements, gestion des erreurs, observabilité, coût de maintenance et lisibilité du run côté métier. C’est à ce niveau que se joue la robustesse réelle d’une intégration API.
Si vous cherchez un cadrage plus large sur la conception, le delivery et l’exploitation de vos flux, découvrez aussi notre expertise en intégration API pour structurer un socle durable, pilotable et utile en production.
Pour cadrer un flux ERP concret, partez aussi de notre page Intégration API ERP: on y tranche la source de vérité sur les articles, stocks, commandes, factures, avoirs, paiements et taxes avant d’ouvrir le connecteur. C’est là qu’on décide si une erreur de schéma part en DLQ, si un retry est autorisé, et si la reprise se fait au document, à la ligne ou au batch.
Dans un projet Divalto, le connecteur utile ne se limite jamais à un appel isolé. Il doit faire circuler un même identifiant de bout en bout entre la fiche article, le stock d’un entrepôt, la commande client, la facture, l’avoir et le paiement. Sans cette continuité, le moindre changement de taxe, de dépôt ou de lot rend les reprises impossibles à lire côté métier.
{
"external_id": "SO-1048",
"document_type": "sales_order",
"warehouse_code": "PAR-01",
"site_code": "FR01",
"vat_rate": 20,
"idempotency_key": "divalto-so-1048-v1",
"batch_id": "batch-2025-12-09-001",
"lines": [
{"sku": "ART-001", "qty": 2, "unit_price": 129.9},
{"sku": "ART-002", "qty": 1, "unit_price": 49.0}
]
}En production, la bonne règle consiste à retry seulement les erreurs transitoires, à envoyer les erreurs de schéma en DLQ et à garder les journaux avec `correlation_id`, `batch_id` et numéro de document. C’est ce trio qui permet de rejouer une ligne, pas toute la journée, et d’éviter qu’un simple rejet de taxe ou d’entrepôt déclenche un reprocessement massif.
Dans les projets Divalto, les intégrations API paraissent simples au départ, puis deviennent rapidement complexes: variantes de modèles, règles métier spécifiques, synchronisations inter-applications, et exigences fortes de continuité de service. Sans cadre commun, les appels API se dispersent et la maintenance devient fragile.
Chez Dawap, nous avons développé un SDK Divalto sous Symfony pour centraliser auth, mapping, normalisation d’erreurs, observabilité et stratégies de reprise. Le connecteur expose des méthodes métier lisibles et réduit drastiquement le code d’intégration dupliqué dans les projets.
Pour la vue globale de notre approche: Intégration API.
Les environnements Divalto (Infinity/Weavy selon contexte) impliquent souvent des schémas API adaptés au métier et des contraintes fortes de cohérence entre gestion commerciale, logistique et facturation. Le connecteur doit absorber ces spécificités sans propager leur complexité à tout le code applicatif.
Les points sensibles sont généralement: référentiels clients/articles, numérotation documentaire, statuts de commande, mouvements de stock et gestion des mises à jour concurrentes. Notre SDK traite ces sujets nativement avec conventions stables et contrôles métier explicites.
En pratique, les difficultés les plus sous-estimées sur Divalto sont rarement techniques "pures". Elles concernent surtout la sémantique métier: cycle de vie d’un document commercial, règles de remise combinées, priorités tarifaires, et dépendance à des référentiels internes (codes tiers, familles, dépôts, taxes, conditions de règlement). Un SDK utile doit intégrer cette couche d’intelligence métier.
Sur Divalto, l’accès API repose sur une gestion stricte des clés et des droits par code projet. En pratique, un utilisateur doit disposer des bons accès ERP/CRM et de l’activation de l’application "Clés d’API" pour générer, régénérer ou révoquer une clé selon le contexte d’intégration.
Les types de clés mentionnés incluent notamment `DatabaseQuery`, `ErpGateway`, `ErpGatewayApi` et `HubApi`. Dans nos intégrations, cela implique de tracer explicitement le type de clé utilisé par flux, d’isoler les secrets par environnement et de contrôler les permissions au plus juste.
La doc indique aussi que la clé affichée à la génération n’est pas récupérable après fermeture de la fenêtre. En exploitation, nous prévoyons donc un runbook de rotation avec recopie immédiate, validation de healthcheck, puis révocation de l’ancienne clé une fois le trafic stabilisé.
Important: ces informations sont susceptibles d’évoluer dans le temps (interfaces myDivalto, types de clés, modèle de droits). Dans l’article, nous les considérons comme valides au moment de rédaction, le 19 février 2026, et nous recommandons toujours une vérification opérationnelle sur l’environnement client avant implémentation.
Lecture des exemples ci-dessous: les formats d’authentification et les structures de réponse marquées "format fourni par la doc" sont contractuels au moment de rédaction. Les exemples marqués "illustratif" servent à montrer une implémentation type et restent à adapter à la version Divalto, au tenant et aux paramétrages projet.
Référence API REST Divalto: Documentation officielle.
Exemple d’appel d’authentification REST (format fourni par la doc):
{
"domain": "[DOMAIN]",
"user": "[LOGIN]",
"password": "[PASSWORD]",
"env": "[ENV]"
}Réponse attendue en succès:
{
"error": 0,
"access_token": "xyz",
"txterr": "",
"infos": ""
}Dans notre SDK Symfony, les secrets restent dans le secret manager et l’`access_token` est caché court terme avec refresh contrôlé, jamais persisté en clair dans les logs.
Le SDK suit une architecture en couches: `DivaltoAuthProvider`, `DivaltoHttpClient`, `DivaltoDomainAdapters`, `DivaltoErrorMapper`, `DivaltoTelemetry`. Symfony sert de socle DI/configuration pour rendre le connecteur réutilisable sur plusieurs projets.
Les adapters sont découpés par domaines métier: `CustomerAdapter`, `ProductAdapter`, `OrderAdapter`, `InvoiceAdapter`, `StockAdapter`. Les DTO internes restent stables pour éviter les effets de bord lors d’évolutions API côté Divalto.
La référence Divalto distingue deux familles utiles en intégration: API REST `RecordSql` (lecture) et services métier (SOAP/REST, souvent avec `param` XML/HMP).
Exemple contractuel (structure d’appel) pour lecture `RecordSql`:
{
"dhoq": "[NOM_DHOQ]",
"recordsql": "[NOM_RECORDSQL]",
"access_token": "xyz",
"parameters": "",
"fields": "CODE,LIBELLE,STATUT",
"where": "Equal_Tiers",
"where_parameters": "tiers=C0000001",
"offset": 0,
"count": 10000,
"orderby": "CODE",
"having": "",
"having_parameters": "",
"infos": ""
}Exemple contractuel (structure de réponse) en succès:
{
"error": 0,
"txterr": "",
"tablename": "TIERS",
"nbrecord": 1,
"records": [
{
"record": {
"TABLE_ID": "2",
"DOS": "998",
"CHAMP1": "valeur"
}
}
],
"infos": ""
}Dans le SDK, ces appels sont encapsulés dans des query objects pour éviter de propager les chaînes `where`/`fields` dans le code applicatif.
Point de vigilance: si le dictionnaire `RecordSql` n’est pas autorisé côté ERP, l’appel échoue même avec un token valide.
Exemple contractuel (structure d’appel) avec transport JSON et `param` XML/HMP:
{
"action": "SYNCHRO_INFINITY_AGILEO",
"param": "<dem><action dos=\"998\" nom=\"INTERROGER_STOCK\"><ref>ALB0001</ref><depot>*</depot></action></dem>",
"access_token": "xyz"
}Exemple contractuel (structure de réponse) en transport JSON avec contenu métier XML:
{
"error": 0,
"result": "<?xml version=\"1.0\" encoding=\"ISO-8859-1\"?>...<action dos=\"998\" nom=\"interroger_stock\" />...",
"txterr": "",
"infos": ""
}Cette hybridation JSON + XML est un point clé Divalto: le SDK doit parser/valider le XML de `result` puis remonter des DTO métiers propres au reste du SI.
Nous ajoutons des parseurs robustes (encodage, décimales, champs absents) pour éviter les erreurs silencieuses.
Exemples illustratifs (à adapter): les mappings métiers spécifiques (noms de champs internes, codes d’action, règles de filtrage) dépendent du paramétrage client et ne doivent pas être copiés en production sans validation sur l’environnement cible.
Notre séquence type: 1. validation et enrichissement du payload entrant, 2. upsert client/référentiel, 3. création commande, 4. confirmation et éventuelle facturation, 5. synchronisation état/stock et ack applicatif.
Chaque étape est isolée, traçable et rejouable. En cas d’échec partiel, on relance l’étape fautive sans dupliquer les opérations déjà validées.
Exemple concret de gouvernance: si la commande est créée mais que l’étape de facturation échoue, le workflow conserve l’identifiant documentaire Divalto, place le flux en statut "à reprendre", et interdit toute recréation tant que l’état réel n’a pas été relu côté ERP.
Cette discipline évite un anti-pattern fréquent: compenser un incident par une nouvelle création documentaire, ce qui produit des écarts comptables difficiles à corriger.
Une métrique utile ici est le nombre de lignes réellement rejouées par batch, pas le nombre total de documents. Si vous voyez remonter trois rejets sur un lot de trois cents commandes, le bon réflexe est d’extraire les trois lignes en cause, pas de relancer les trois cents. C’est ce découpage qui garde les délais de reprise courts et permet au run de distinguer un incident isolé d’un problème de référentiel.
Exemple utile côté run: un article peut être valide, un stock disponible, mais une taxe absente peut bloquer la ligne de commande au dernier moment. Dans ce cas, on n’annule pas le document complet. On isole la ligne, on la place en DLQ avec le code taxe manquant, puis on rejoue uniquement le sous-lot après correction du référentiel. Cette mécanique est celle qui rend un intégrateur supportable en production.
Divalto devient vite sensible dès que plusieurs flux se croisent: un `payload` peut contenir un client, une commande, une facture ou un mouvement de stock. Le SDK doit donc séparer le `mapping` par type d’objet et garder la clé d’`idempotence` du premier essai jusqu’au replay final. Si le `rate limit` ou le `token` d’accès pose problème, c’est le transport qui doit se rétablir, pas le document métier.
Les webhooks applicatifs ou les retours du front-office doivent être absorbés via une `queue`, puis consolidés en `batch` pour éviter de rejouer la même création plusieurs fois. Un `retry` n’est utile que s’il s’agit d’un incident technique transitoire. Si la commande est déjà validée dans Divalto, on ne la recopie pas; on corrige seulement la ligne fautive ou la facture associée.
Le support doit aussi comprendre la différence entre un rejet de schéma et une divergence métier. Une taxe manquante, un entrepôt invalide ou un statut de livraison incohérent ne se traitent pas comme une simple erreur API. Le SDK doit isoler le sous-lot fautif, envoyer la ligne en DLQ si nécessaire et laisser les autres documents continuer leur cycle sans être republiés.
Sur le terrain, le meilleur signal de fiabilité reste simple: un article synchronisé, une commande créée, une facture publiée, un stock réservé et un avoir qui pointe bien le document d’origine. Si chaque objet garde sa trace et son historique, la reprise devient explicable, et l’équipe métier peut corriger le bon périmètre sans ouvrir un incident de plus.
Divalto decision map
- payload -> client, order, invoice or stock movement
- api endpoint -> read or write according to object type
- queue -> isolated replay by business event
- batch -> grouped by source and document family
- retry -> technical only
- idempotence -> same document, same outcome
- dlq -> schema or referential faultLe SDK applique retries bornés, timeout par opération et backoff progressif. Les écritures sensibles sont protégées par des clés d’idempotence métier pour empêcher les doublons de commande/facture en cas de timeout.
Les erreurs sont normalisées en catégories actionnables: auth/permission, contrat payload, erreur métier, erreur technique transitoire. Cette normalisation accélère le diagnostic et fiabilise les traitements de reprise.
Nous maintenons une matrice de traitement d’erreurs dédiée Divalto: erreur référentiel -> correction fonctionnelle puis replay, erreur technique transitoire -> retry automatique borné, erreur documentaire bloquante -> escalade métier + reprise manuelle guidée. Ce cadrage réduit fortement les incidents "gris" où personne ne sait quoi faire.
Autre point niche: la gestion des collisions de mise à jour (concurrence entre front-office, opérateur et batch). Le SDK sérialise les opérations critiques par clé documentaire pour conserver l’ordre métier attendu.
Nous combinons tests unitaires (mappers, validators), tests d’intégration API (nominaux et dégradés), puis tests de non-régression sur scénarios métier critiques (commande, annulation, facture, correction stock).
Les cas couverts incluent: retry sur timeout, conflit de version, payload incomplet, idempotence sur réémission, et contrôle de cohérence documentaire.
Nous ajoutons des jeux de tests métier "à forte valeur": changement de tarif en cours de flux, indisponibilité partielle d’un article, split de livraison, et avoir partiel après facturation. Ces scénarios sont ceux qui révèlent les vraies faiblesses d’un connecteur en production.
Référence méthodologique: Tests API, stratégie et bonnes pratiques.
Postman est utilisé pour qualifier rapidement les endpoints, rejouer des cas métiers et partager des collections versionnées entre développeurs et équipes recette. Les mocks permettent de reproduire des cas limites sans dépendre en permanence d’un environnement Divalto complet.
Nous alignons systématiquement contrats de payload, implémentation SDK et scénarios de test pour éviter les dérives.
Nous documentons aussi des "fixtures de non-régression" par version d’API Divalto: payloads validés, réponses attendues et règles de compatibilité descendante. C’est essentiel pour maîtriser les évolutions sans casser les flux existants.
D’après la documentation "Actions métiers exposées par les SW" (mise à jour indiquée au 10 juin 2022), chaque service métier expose des exemples de zones `parameters` ou `data` directement exploitables dans Postman. La collection Postman complète peut être demandée au support via un ticket adressé à l’Academy Technique.
Article utile: Postman pour industrialiser vos tests API.
Chaque appel API est corrélé (trace id), journalisé (endpoint, durée, statut, retry_count) et enrichi d’un code erreur normalisé. Les dashboards suivent latence, taux d’erreur, backlog et délai moyen de reprise.
Des runbooks ciblés (auth, mapping, conflits métier, saturation) réduisent le temps de diagnostic et sécurisent l’exploitation.
Complément: Observabilité et runbooks API.
Vue d’ensemble du panel: Découvrir le guide des SDK API ERP Dawap.
SDK API ERP Microsoft Dynamics 365
Sur Divalto, la réussite d’un projet d’intégration ne se mesure pas au nombre d’APIs branchées, mais à la robustesse du système de flux dans la durée. Une intégration "fonctionnelle" le jour du go-live peut devenir fragile en quelques semaines si les règles de mapping, les clés d’idempotence, les traitements de reprise et la gouvernance des versions ne sont pas cadrés dès le départ.
Le bon cadrage consiste à traiter quatre dimensions en parallèle: 1. périmètre fonctionnel priorisé (clients, commandes, factures, stock, statuts), 2. contrat technique explicite (payloads, erreurs, timeouts, retries, traçabilité), 3. stratégie run (monitoring, alerting, runbooks, ownership), 4. trajectoire d’évolution (scalabilité, dette technique, changements d’API, conformité). Sans cet alignement, les incidents se multiplient au moment où les volumes augmentent.
Dans nos missions, nous livrons donc plus qu’un connecteur: un cadre opérable. Cela inclut une architecture SDK maintenable sous Symfony, des scénarios de test réalistes, une matrice d’erreurs actionnable, des conventions de logging corrélées, et une documentation exploitable à la fois par les développeurs, les architectes et les équipes d’exploitation.
Cette approche permet de réduire le time-to-value sans compromettre la stabilité du SI. Les équipes métier gagnent en fluidité opérationnelle, les équipes techniques gardent la maîtrise des évolutions, et la direction dispose d’une visibilité claire sur les risques et la performance des flux critiques.
Un projet Divalto ne devient vraiment robuste que lorsqu’il accepte que commerce, logistique et finance ne travaillent jamais exactement au même rythme. Le SDK doit donc permettre à chaque endpoint de répondre sur le bon niveau de détail, avec le bon payload et le bon mapping métier. Dès qu’un flux touche une commande, une facture et un stock, le moindre retard de synchronisation peut se transformer en écart opérationnel visible.
Cas concret: une promotion commerciale démarre, le stock en entrepôt descend plus vite que prévu et la finance doit continuer à facturer les commandes déjà validées. Si la plateforme Divalto répond lentement, le connecteur place la demande en queue, rejoue un retry borné et garde une clé d’idempotence pour éviter les doubles écritures. Le runbook doit aussi préciser ce que l’on laisse en batch et ce qui doit rester en temps réel pour ne pas bloquer l’activité.
Ce type de cadrage change beaucoup de choses pour l’exploitation. Les incidents deviennent lisibles, les responsabilités sont claires et l’équipe support peut expliquer si un écart vient d’un webhook traité en retard, d’une rate limit côté fournisseur ou d’une correction de TVA à appliquer a posteriori. Le SDK cesse alors d’être un simple lien technique pour devenir un outil de pilotage métier.
Le point décisif reste la lisibilité du parcours de bout en bout. Quand le commerce déclenche une action, que la logistique corrige un stock et que la finance valide un mouvement, chaque équipe doit pouvoir relire la même histoire sans interprétation supplémentaire. C’est ce niveau de clarté qui rend le SDK exploitable en production, même quand les canaux évoluent à des rythmes différents.
Divalto devient réellement solide quand le SDK aligne le stock, la commande et la facture dans une même logique de synchronisation. Le rôle du connecteur n’est pas d’additionner les appels, mais de garantir que chaque endpoint reçoit le bon payload, avec le bon token et les bons identifiants métier. Sans ce cadre, les écarts entre entrepôt, commerce et comptabilité s’accumulent très vite.
Cas concret: un dépôt signale une rupture, le commerce bloque une vente et la finance doit toujours pouvoir facturer les commandes déjà validées. Si un webhook de changement d’état revient en retard, le SDK l’oriente vers une queue, rejoue le retry par batch et maintient l’idempotence des mises à jour. Le support doit alors voir immédiatement si l’incident vient du mapping, de la latence ou d’un rate limit côté fournisseur.
Le vrai test d’un connecteur Divalto n’arrive pas lors du premier appel réussi, mais quand le flux devient asymétrique. Un canal commercial peut créer une commande en quelques secondes, alors que la finance attend une validation de TVA, une référence de facture et un état de préparation logistique avant d’ouvrir le circuit complet. Le SDK doit absorber ce décalage sans casser la cohérence du dossier client.
Cas concret: un magasin ouvre la vente en ligne, le dépôt publie un niveau de stock et un batch nocturne doit recaler les écritures. Si une API en aval répond trop lentement, le connecteur conserve le payload, la clé d’idempotence et le contexte du token pour rejouer le retry au bon moment. Le support ne doit jamais se demander si l’écart vient d’un mauvais mapping, d’un webhook en retard ou d’une vraie rupture de synchronisation.
Dans la pratique, la bonne approche consiste à séparer les flux critiques des flux de confort. Les stocks et les écritures financières restent prioritaires, tandis que les enrichissements secondaires passent en queue ou en batch. Ce découpage permet d’isoler les incidents, de mieux lire les latences et d’éviter qu’un fournisseur saturé ne bloque l’ensemble du commerce.
Besoin d’un accompagnement sur mesure pour cadrer, construire ou fiabiliser vos flux ? Découvrez notre offre d’intégration API sur mesure.
Articles complémentaires à lire ensuite : pour prolonger ce sujet, comparez aussi notre guide complet d’intégration API, notre article sur l’architecture sync, async et event et notre guide sur les tests API en production.
Nous accompagnons les équipes produit et techniques dans la conception, l’intégration et l’industrialisation d’APIs. Notre mission : construire des architectures robustes, sécurisées et évolutives, alignées sur vos enjeux métier et votre croissance.
Vous préférez échanger ? Planifier un rendez-vous
Les flux Odoo exigent une lecture fine de JSON-RPC, des modèles métier et des règles de transition documentaires. Ce guide détaille comment Dawap structure un SDK Symfony pour synchroniser clients, commandes, factures et stocks avec idempotence, retries maîtrisés et traçabilité run.
SAP implique des contraintes élevées sur la volumétrie, la cohérence des données et la robustesse des workflows critiques. Nous y détaillons notre SDK Symfony pour orchestrer les flux logistiques et financiers avec contrôle d’état strict, résilience réseau et supervision orientée production.
Dynamics 365 nécessite des échanges API REST sécurisés et cohérents sur plusieurs domaines métier simultanément. Ce guide explique notre SDK Symfony pour synchroniser ventes, clients, stocks et finance, tout en conservant une observabilité fine et une gestion d’incidents pilotable.
Les intégrations Sage demandent une forte rigueur sur les écritures, les référentiels et les statuts comptables. Cet article montre comment Dawap conçoit un SDK Symfony pour normaliser les flux, sécuriser la reprise sur incident et fournir une observabilité exploitable par les équipes run.
Nous accompagnons les équipes produit et techniques dans la conception, l’intégration et l’industrialisation d’APIs. Notre mission : construire des architectures robustes, sécurisées et évolutives, alignées sur vos enjeux métier et votre croissance.
Vous préférez échanger ? Planifier un rendez-vous