Choisissez un résultat, pas une liste de fonctions
Une démonstration peut rendre chaque connexion utile tout en laissant le résultat opérationnel indéfini. Commencez par un résultat observable de bout en bout. Dans l'exemple fictif, une commande de gros doit être saisie une fois, tarifée selon des conditions approuvées, réservée sur le stock disponible, validée, exécutée, facturée et rapprochée. Ce périmètre n'est pas un manque d'ambition : il révèle si l'intégration termine réellement le travail.
Écrivez les états de départ et d'arrivée avant la configuration. Le départ est une demande valide ; l'arrivée est un ensemble relié de commande, expédition, facture et paiement sans doublon ni solde inexpliqué. Les fonctions qui n'aident pas ce parcours peuvent attendre.
Nommez le propriétaire de chaque donnée
L'intégration échoue discrètement lorsque deux systèmes peuvent modifier le même fait. Désignez le registre de référence pour le produit et les conditions approuvées, le stock disponible, l'approbation, l'expédition, la facture et le paiement. Décidez qui écrit, qui lit seulement et comment une correction revient au propriétaire du registre.
Conservez aussi les liens de référence. Une expédition sans référence de commande ou un paiement sans référence de facture peut paraître réussi dans des tableaux distincts tout en restant non résolu comme transaction unique.
Testez les exceptions avant le volume
Le parcours normal prouve peu à lui seul. Envoyez deux fois la commande fictive, retirez une correspondance produit, modifiez le stock disponible, retenez l'approbation, expédiez une partie seulement et créez un écart de paiement. Chaque exception doit avoir un état visible et un responsable. Les nouvelles tentatives silencieuses, doublons et corrections hors registre sont des échecs même si l'écran final devient vert.
Gardez une preuve simple : référence d'entrée, enregistrement produit, heure de décision, responsable de l'exception et résolution. Le but n'est pas d'imiter tous les futurs problèmes, mais de vérifier que le contrôle subsiste lorsque le parcours attendu se rompt.
Accordez-vous sur le sens de l'acceptation
L'acceptation doit être observable. Une demande crée une commande ; l'article et la base de prix restent traçables ; le stock est réservé avec un lieu et une heure ; l'approbation est enregistrée ; la quantité expédiée correspond à la base de facturation ; et le solde final est expliqué. Mesurez le flux achevé, pas la disponibilité du connecteur ni le nombre de champs synchronisés.
Consignez séparément les hypothèses ouvertes. Une capacité décrite dans la documentation peut dépendre d'une édition, d'un marché, d'une configuration ou d'une autre application. Si la condition exacte n'est pas vérifiée, gardez-la comme question et non comme résultat accepté.
Étendez par étapes et gardez un retour arrière
Après validation du flux, ajoutez une seule dimension à la fois : gamme de produits, site, canal ou type d'exception. Rejouez les mêmes preuves d'acceptation à chaque étape afin d'identifier le changement qui a introduit l'échec.
Avant la bascule, documentez comment arrêter les nouvelles écritures, terminer le travail en cours, corriger les doublons et restaurer le dernier état fiable. Le retour arrière ne suppose pas que la plateforme échouera ; il prouve que l'entreprise, et non la connexion, reste aux commandes.
À la prochaine note.
← Retour aux articles