Services
Commandes, paiements, stock et opérations de vente conçus autour de la manière dont l’entreprise exécute réellement ses commandes.
Le client voit le catalogue, le panier et le checkout. L’entreprise doit coordonner commande, paiement, stock, entrepôt, facture, expédition, CRM, communication, retours et remboursements. Un workflow eCommerce utile attribue une responsabilité claire à chaque élément et rend les exceptions visibles.
GiSoft conçoit et modernise ces workflows sans supposer que chaque boutique a besoin des mêmes états, intégrations ou architecture. Le processus doit correspondre à la vente de produits physiques, services numériques, abonnements ou commandes B2B.
Il faut préciser quand une commande existe, quand le stock est réservé, qui peut l’approuver, quand la facture est créée et ce que signifient annulation ou remboursement. L’état de commande relève de la logique métier côté serveur, pas d’un écran dans le navigateur.
Dans de nombreuses entreprises, une référence interne créée au checkout relie paiement, réservation, ERP, facture, expédition et support. Cela facilite souvent la récupération, mais la bonne séquence dépend du produit et du processus commercial.
Le retour depuis une page de paiement ne constitue pas une confirmation définitive. Le client peut fermer son navigateur, la redirection peut échouer ou le paiement peut rester en attente. L’application doit utiliser la confirmation vérifiée côté serveur du prestataire, ou un autre signal de règlement convenu, avant de mettre à jour son propre état métier de paiement.
Autorisation, capture et confirmation sont des notions distinctes. Un prestataire peut d’abord réserver les fonds, un autre signaler plus tard le paiement terminé par webhook. Le workflow de commande doit représenter le sens utile à la boutique : paiement en attente, autorisé, payé, refusé, annulé, remboursé ou à vérifier.
Disponibilité, réservation et décrémentation du stock ne sont pas synonymes. La disponibilité indique si un article peut actuellement être proposé. La réservation attribue temporairement des unités à une commande selon des conditions définies. La décrémentation enregistre le mouvement de stock définitif ou lié à l’exécution. L’ERP ou le WMS peut être le système de référence, mais la boutique doit savoir ce qu’elle peut afficher et à quel moment une réservation expire ou est libérée.
Imaginons une ancienne boutique Symfony qui a commencé avec catalogue, panier, checkout, commandes et e-mails. Elle a ensuite reçu des prestataires de paiement, des synchronisations ERP et WMS, une API de transporteur, la facturation et des mises à jour CRM. Si le contrôleur de checkout appelle directement tous les systèmes externes, un prestataire lent peut retarder le client et un échec partiel devient difficile à comprendre.
Une amélioration contrôlée conserve les règles de commande existantes et place un workflow applicatif entre le checkout et les services externes. Les adaptateurs de paiement, ERP, entrepôt, facture et notification gèrent alors leurs propres frontières. Il n’est pas nécessaire de réécrire toute la boutique : on peut commencer par la zone qui crée le plus de risque opérationnel.
Un succès HTTP ou la réception d’un webhook ne signifie pas forcément que tout le processus métier est terminé. Un timeout ne prouve pas non plus que l’opération externe a échoué : l’ERP, le prestataire de paiement ou le service de facturation peut avoir traité la demande avant la perte de réponse.
Enregistrez la tentative locale, utilisez un identifiant stable de demande ou métier lorsque le système externe le prend en charge, et rapprochez les cas incertains du système de référence. L’idempotence signifie qu’une opération répétée ne devrait pas produire d’effet métier supplémentaire intentionnel. Elle dépend de la conception de l’application et, si besoin, du support du prestataire ou d’un identifiant commun ; un identifiant seul ne garantit rien.
Les relances doivent cibler les erreurs temporaires et être limitées. Des données invalides ou l’absence de décision métier exigent une correction ou une revue humaine. Les traitements en arrière-plan conviennent aux mises à jour ERP, à la facturation, à la synchronisation du stock et aux notifications, afin que le checkout n’attende pas chaque étape suivante.
Annulation, remboursement et retour sont des événements métier différents. Une annulation peut libérer une réservation avant expédition ; un remboursement peut suivre le règlement ; un retour peut exiger une décision d’entrepôt et une correction comptable. Les règles doivent être explicites, y compris les droits d’approbation et le système qui enregistre l’état final.
Un rollback de base de données ne peut pas annuler un paiement finalisé, un e-mail envoyé ou une action ERP. La récupération peut demander un rapprochement, une action compensatoire, une relance sûre ou un traitement manuel. La supervision doit montrer les commandes qui attendent trop longtemps, les tâches échouées, les écarts de paiement, les conflits de stock et les cas à examiner.
Utilisez l’autorisation pour les changements administratifs, protégez les données client et financières, vérifiez les webhooks de paiement et gardez les identifiants des prestataires hors du code et des logs inutiles. Testez les parcours critiques : créer une commande une seule fois, gérer des notifications répétées, réserver et libérer le stock, facturer et récupérer après une erreur.
GiSoft part du processus de commande existant, identifie le système de référence et les points de risque, puis améliore les frontières les plus importantes. La bonne conception dépend du modèle de vente, de la politique de stock et des systèmes connectés. L’objectif est un processus que l’équipe comprend et peut récupérer, pas la promesse que chaque dépendance externe sera parfaite.
