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.
Le 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: Présentation des SDK API ERP développés par 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.
Pour approfondir côté service: Intégration API ERP Divalto et notre offre Intégration API.
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