Des flux cartographiés
Définir les données échangées, leur fréquence et leurs règles de transformation.
Des applications isolées créent des références incohérentes, des transferts manuels et des erreurs difficiles à retracer. Une connexion technique sans règles métier peut seulement déplacer le problème.
Nous définissons la source de référence, les responsabilités et le sens des échanges avant de choisir un connecteur. Le fonctionnement dégradé et la reprise sont étudiés dès la conception.
Définir les données échangées, leur fréquence et leurs règles de transformation.
Évaluer API, connecteurs et traitements planifiés selon les applications disponibles.
Prévoir les droits, les journaux, les alertes et les procédures de reprise.
Exemple de contrat CRM–ERP à préciser avec les propriétaires des deux systèmes.
| Donnée échangée | Source et règle | Contrôle à réception |
|---|---|---|
| Client | ERP : identifiant de référence | Identifiant reconnu et actif |
| Commande | CRM : commande approuvée uniquement | Identifiant non déjà traité |
| Statut de traitement | ERP : résultat et référence retournés | Accusé associé à la commande |
Inventaire des interfaces, contrat de données, prototype, tests de bout en bout et tests de reprise. Les accès sont limités au nécessaire et les secrets restent côté serveur ; les conditions d’exploitation sont transmises.
Quelques éléments pour rendre le cadrage et la validation plus concrets.
Suivre un échange de son émission à son accusé de réception, puis tester un identifiant inconnu, un doublon et une reprise après interruption. Vérifier les données reçues, la traçabilité et l’absence de secrets dans les journaux.